aMule Forum

English => Compilation problems => Topic started by: Gaznevada on May 21, 2008, 02:51:20 PM

Title: Portability issues on unices
Post by: Gaznevada on May 21, 2008, 02:51:20 PM
Portability issue?

"case PHP_VAL_STRING: printf("string(%zd) \"%s\"\n", strlen(node->str_val), node->str_val); break;"

in src/webserver/src/php_core_lib.cpp

<stdio.h> and standard libc library

- in IRIX (for sure, tested)

and probably in

- AIX, see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/printf.htm
- HP-UX, see http://docs.hp.com/en/B2355-90695/printf.3S.html
- Solaris, see http://docs.sun.com/app/docs/doc/816-0213/6m6ne387j?a=view

does not have a specific format descriptor for size_t
returned by strlen (a very quick look at the man page, not
a real test).

Given that the problem pops up in runtime and "the result
is unpredictable (K&R)" it is hard to figure out what really
happens without a core debug.

IMVHO I suggest to retain the old "%d" format descriptor
or check with configure the sanity of executable code with
a "%zd" as a format descriptor.

Cheers

--
Gaznevada


Title: Re: Portability issues on unices
Post by: lfroen on May 21, 2008, 03:23:55 PM
Facts first: (quote from "man 3 printf")
Quote
       z      A  following integer conversion corresponds to a size_t or ssize_t argument. (Linux libc5 has Z with this meaning. Don't use
              it.)

CONFORMING TO
       The fprintf, printf, sprintf, vprintf, vfprintf, and vsprintf functions conform  to  ANSI  X3.159-1989  ("ANSI  C")  and  ISO/IEC
       9899:1999 ("ISO C99").  The snprintf and vsnprintf functions conform to ISO/IEC 9899:1999.

So, there's reason for "%z". Are you really poses AIX machine?
Title: Re: Portability issues on unices
Post by: Gaznevada on May 21, 2008, 03:47:53 PM
Facts first: (quote from "man 3 printf")
Quote
       z      A  following integer conversion corresponds to a size_t or ssize_t argument. (Linux libc5 has Z with this meaning. Don't use
              it.)

CONFORMING TO
       The fprintf, printf, sprintf, vprintf, vfprintf, and vsprintf functions conform  to  ANSI  X3.159-1989  ("ANSI  C")  and  ISO/IEC
       9899:1999 ("ISO C99").  The snprintf and vsnprintf functions conform to ISO/IEC 9899:1999.

So, there's reason for "%z". Are you really poses AIX machine?

I understand that there is a reason for "%z". What I'm trying to say is:

1) Not all Unix flavors have "%zd"

2) IRIX does not have it, for sure.

3) Taking a quick look at man pages of printf for AIX, HP-UX and Solaris, there is
no mention of a specific format descriptor for size_t . Probably it means that
"%zd% is an unvalid format descriptor on such machines.

4) I have only a direct experience on IRIX.

5) Your "man 3 printf" is probably issued on a Linux machine. Isn't it? The point
is that I'm not talking about Linux.

Cheers

--
Gaznevada
Title: Re: Portability issues on unices
Post by: GonoszTopi on May 21, 2008, 04:09:28 PM
Quote from "man 3 printf":
Quote
CONFORMING TO

       [...]

       glibc 2.1 adds length modifiers hh,j,t,z and conversion characters a,A.

So, %zd is not valid before glibc 2.1, and is valid only with glibc. This surely breaks builds that does not use the GNU C library (e.g. MSW, if it wasn't broken already; I don't know whether Macs use glibc or not). There already has been a request (http://bugs.amule.org/view.php?id=1289) not to use glibc-specific features, or at least test for them correctly. Let's keep us to maximum portability.
Title: Re: Portability issues on unices
Post by: Gaznevada on May 21, 2008, 04:33:52 PM

This surely breaks builds that does not use the GNU C library


Worse: build goes smoothly to an end but error pops up at runtime (SIGSEGV and
coredump) breaking amuleweb every now and then.

Cheers

--
Gaznevada


Title: Re: Portability issues on unices
Post by: lfroen on May 21, 2008, 08:41:32 PM
Mac is OK with %z. Cygwin uses glib too, so I suppose it's safe bet that MSW is OK too? If so, I see no problem.
Title: Re: Portability issues on unices
Post by: Kry on May 21, 2008, 09:47:51 PM
Why is printf even used for anything?
Title: Re: Portability issues on unices
Post by: GonoszTopi on May 21, 2008, 10:01:24 PM
[...] I suppose it's safe bet that MSW is OK too?
MinGW uses msvcrt, and most likely MSVC too.
Title: Re: Portability issues on unices
Post by: lfroen on May 22, 2008, 08:00:07 AM
Why is printf even used for anything?
For printing to stdout?
Title: Re: Portability issues on unices
Post by: lfroen on May 22, 2008, 11:30:55 AM
The whole issue is of cause, silly. If %z present problem for MSVC - replace it with %d
Title: Re: Portability issues on unices
Post by: Kry on May 22, 2008, 01:02:19 PM
Why is printf even used for anything?
For printing to stdout?

What happened to std::cout ?
Title: Re: Portability issues on unices
Post by: lfroen on May 22, 2008, 02:47:08 PM
What happened to std::cout ?
No idea. Never used it (why bother? - something terrible happened to printf()?)
Title: Re: Portability issues on unices
Post by: Kry on May 22, 2008, 03:36:33 PM
Yeah, that you refuse to remove a format spec that doesn't exist in some implementations ;)

IMHO, printf should be avoided for C++ implementations and std::cout used.

 Anyway, my question stands, why is amuleweb printing anything like that to the console? That doesn't seem to be a informative message for the user.
Title: Re: Portability issues on unices
Post by: Gaznevada on May 22, 2008, 07:08:19 PM
Just a remark: I'm not a developer, I'm a final user so
I'm primarily interested in a workin' code.

Now I put myself in John Smith's shoes: when I connect
to amuleweb from an external connection and after a while
the connection hangs up and I see a huge file named "core"
(assuming that I know what a "core" file is, I mean...)
my first thought is "aMule is broken, it does not work, let's
wipe it away".

Well, I think this is not a good service for aMule and it's
immaterial if developers choose to use printf or not:
I think that the only wrong choice is moving away from
portability.

My two cents.

Cheers

--
Gaznevada
Title: Re: Portability issues on unices
Post by: Kry on May 22, 2008, 07:45:50 PM
We all know the application mustn't crash. We're talking solutions.
Title: Re: Portability issues on unices
Post by: lfroen on May 22, 2008, 08:46:43 PM
Yeah, that you refuse to remove a format spec that doesn't exist in some implementations ;)
Refuse to remove? Should I start quote myself?

IMHO, printf should be avoided for C++ implementations and std::cout used.
<shrugs>

Anyway, my question stands, why is amuleweb printing anything like that to the console? That doesn't seem to be a informative message for the user.
For 2 purposes:
1. For messages about syntax errors in script
2. For printing output of var_dump() of php script, which is used for page debugging.

Those are not messages for user, but for page developer.
Title: Re: Portability issues on unices
Post by: GonoszTopi on May 22, 2008, 09:06:39 PM
Anyway, my question stands, why is amuleweb printing anything like that to the console? That doesn't seem to be a informative message for the user.
For 2 purposes:
1. For messages about syntax errors in script
2. For printing output of var_dump() of php script, which is used for page debugging.

Those are not messages for user, but for page developer.

IMHO both should be reported to the requester.

I mean if I was a page developer and I found that the PHP engine prints var_dump() to somewhere else than the resulting HTML page, I would be very disappointed. The same applies to syntax errors in scripts: the resulting page should describe the error.

I mean this is the behaviour of all PHP interpreters I know, why should amuleweb differ?

Not to mention that there's no console to print to if amuleweb was started automagically by amule(d).
Title: Re: Portability issues on unices
Post by: Gaznevada on May 22, 2008, 10:04:20 PM
We all know the application mustn't crash. We're talking solutions.

Reading previous posts, that wasn't so clear to me. Anyway.

--
Gaznevada
Title: Re: Portability issues on unices
Post by: lfroen on May 23, 2008, 12:29:09 PM
IMHO both should be reported to the requester.
This is wrong all over. For real web application this may easy become security issue. ALL errors (from database, script, etc) should be reported to apache log, and not to page requester.

I mean if I was a page developer and I found that the PHP engine prints var_dump() to somewhere else than the resulting HTML page, I would be very disappointed. The same applies to syntax errors in scripts: the resulting page should describe the error.
This suggest that you never seen real PHP (or ASP or CGI), because this is exactly how it works. Errors going to apache log or to stderr when running standalone.

There's also technical reason for this behavior. You can't just dump your error message in the middle of HTML page. You don't know the context, so there's no way to ensure your error message is visible.

I mean this is the behaviour of all PHP interpreters I know, why should amuleweb differ?
That's exactly my point, you see.

Not to mention that there's no console to print to if amuleweb was started automagically by amule(d).
This because amuleweb is not real webservser, which typically have log file. I may add option for amuleweb to create log for this very purpose, but it looks like overkill to me. There's not many people going to develop templates IMHO, and those who do can start it from command line: "amuleweb -q" isn't very complicated command.