Re: Return value of malloc(0)
On Saturday 01 July 2006 04:35, Matthias Andree wrote: Pat Lashley [EMAIL PROTECTED] writes: BUT, that said, the safest and most portable coding practice would be: // The C standard does not require malloc(0) to return NULL; // but whatever it returns MUST NOT be dereferenced. ptr = ( size == 0 ) ? NULL : malloc( size ) ; Safest (avoiding null derefence) would instead be: ptr = malloc(size ? size : 1); BTW: // is not a valid C89 comment, but a GCC-ism. It's valid in C99 though. :) -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Sat, 01-Jul-2006 at 10:35:47 +0200, Matthias Andree wrote: Pat Lashley [EMAIL PROTECTED] writes: BUT, that said, the safest and most portable coding practice would be: // The C standard does not require malloc(0) to return NULL; // but whatever it returns MUST NOT be dereferenced. ptr = ( size == 0 ) ? NULL : malloc( size ) ; Safest (avoiding null derefence) would instead be: ptr = malloc(size ? size : 1); I hacked malloc.c to do exactly this automatically, just for testing. 15 Minutes after rebooting (and after doing a lot of desktop switching and opening and closing of windows) the X-server ran out of memory :-). I assume there are lots of programs out there which do malloc(0) but only firefox (and apparently seamonkey) dereference the returned non-NULL pointer and crash therefore. -Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Fri, 30-Jun-2006 at 12:15:21 -0400, Pat Lashley wrote: I went wandering through the C Working Group archives for the heck of it, and apparently a lot of people were confused over this, thinking either as you did or that unique meant it would a value unique to the usage of malloc(0). It's been clarified recently (and will be in the next revision of the standard) to the meaning you understood. ... This is wandering into -standards territory, though. In any case, the answer to thread's original question is mozilla should fix its code to not assume malloc(0)==NULL. Agreed. (With the usual observation that they, too, are a mainly volunteer-based project; and would probably appreciate the inclusion of a patch Well, I was unsure of the correct behaviour. That's why I came here:-). From all what I've read so far, I can summarize: - Returning a non-NULL value from malloc(0) is completely legal. - We return a non-NULL value which, when dereferenced, always make the application crash (as a warning). See the commit message of rev. 1.60 of malloc.c: snip -- phkmalloc-evilchecks++; If zero bytes are allocated, return pointer to the middle of page-zero (which is protected) so that the programme will crash if it dereferences this illgotten pointer. Inspired Urged by:Theo de Raadt [EMAIL PROTECTED] snap -- - What we do isn't 100% perfect since we always return the same value for each malloc(0). - It was firefox' fault to crash. - The manpage is heavily misleading. Firefox must be fixed but some stuff can be done in FreeBSD as well: - If we keep our current behaviour we have to change the manpage. (As I said before, I could do that if someone will commit it later.) - We could reverse the meaning of the V-flag (or, introduce a new flag to avoid confusion). This would mean that by default a malloc(0) will return NULL in future. The new flag can be used to change this behaviour to the way it was done before: We hand out the value which, when dereferenced, make the programme crash as a warning to the author. We note in the manpage that it is not 100% legal since we always use the same value. with the bug report. And, of course, that the original poster of this thread should file a bug report with the Mozilla project.) Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=343283 It wasn't me who created this PR but the author of the extension which actually revealed the bug. -Andre -- UNIX is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a bootsector virus. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Pat Lashley [EMAIL PROTECTED] writes: BUT, that said, the safest and most portable coding practice would be: // The C standard does not require malloc(0) to return NULL; // but whatever it returns MUST NOT be dereferenced. ptr = ( size == 0 ) ? NULL : malloc( size ) ; Safest (avoiding null derefence) would instead be: ptr = malloc(size ? size : 1); BTW: // is not a valid C89 comment, but a GCC-ism. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FLEX, was Re: Return value of malloc(0)
On Thu, 2006-Jun-29 15:09:23 -0700, Randall Hyde wrote: How about feeding the C source through the preprocessor, stripping out the #line directives, compiling it and posting the exact gcc error and source context. Okay, I'll try that when I get home. But I was kind of under the impression that *GCC* runs the preprocessor on the input, during compilation :-). It does but, as you pointed out, the input line you posted doesn't obviously correlate with the error report. Explicitly pre-processing the source and stripping out the #line directives means that you can then correlate the error message with the actual line that cc1 is compiling. -- this would appear to be a generic problem with using FLEX output under BSD and I thought a quick question would affirm/deny that thought. Well, I just did a check of some flex code I have lying around and it did not report any syntax errors or unexpected warnings. And, since flex is used several times during a buildworld, any generic problems would show up very quickly. -- Peter Jeremy pgpgHVxdRwirz.pgp Description: PGP signature
Re: Return value of malloc(0)
On Fri, Jun 30, 2006 at 06:59:37AM +0200, Johannes Weiner wrote: Hi, On Thu, Jun 29, 2006 at 07:29:16PM +0200, Matthias Andree wrote: No, sir. Operator precedence: assign first, and then compare, thus the comparison will always be true (else you'd be comparing to undefined values, which isn't any better). You might as well write: foo = malloc(0); /* make noise */ Ok, just for having it done: if (foo == (foo = some_val)) .. would be right to check if foo stayed the same. No? There is no way to see a 0x800 return from malloc(0) as error. So noone should actually use malloc(0) and check the size_t argument before passing it, I guess. But noone should dereference something beyound malloc'ed size. The following code is broken no matter if x is 0 or anything else, you always end up accessing data beyond allocated range: foo = malloc(x); foo[x] = bar; It might be Ok not to check x when calling malloc, but is always required to check if you access something outside the malloc'ed range unless you can trust your size - in which case you wouldn't had malloc'ed zero bytes anyway. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
I went wandering through the C Working Group archives for the heck of it, and apparently a lot of people were confused over this, thinking either as you did or that unique meant it would a value unique to the usage of malloc(0). It's been clarified recently (and will be in the next revision of the standard) to the meaning you understood. Specifically: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. But if it did actually perform a minimum allocation'; wouldn't it have to return a different value every time to maintain the free() semantics? I think that's another way of looking at the same confusion. If minimum is zero, then using a sentinel value (as in FreeBSD) works. But the standard, as you quoted above, says 'as if the size were some NONZERO value'; so using a sentinel value is NOT standards-compliant. Our malloc() could be easily fixed to be standards-compliant by removing the special handling for ZEROSIZEPTR in malloc.c; then allocations of 0 bytes will be rounded up to 16, just like all other alloations of less than 16 bytes. However, that would lose much of the bug-finding advantage of the current behaviour. But how often does this particular type of bug occur? If often enough, how hard would it be to make zero-sized allocations come from some special chunk of address space that is reserved to always generate a fault on access (from user space)? (And, of course, fix realloc() to recognize pointers in that range and do the right thing.) Also, under what circumstances could a zero-sized allocation fail (using our current scheme)? Is it really useful to maintain the distinction between 'failed' and 'successfully allocated no space'? Would it be better to just take the simple route of returning NULL for zero-sized allocations? This is wandering into -standards territory, though. In any case, the answer to thread's original question is mozilla should fix its code to not assume malloc(0)==NULL. Agreed. (With the usual observation that they, too, are a mainly volunteer-based project; and would probably appreciate the inclusion of a patch with the bug report. And, of course, that the original poster of this thread should file a bug report with the Mozilla project.) -Pat ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
No, sir. Operator precedence: assign first, and then compare, thus the comparison will always be true (else you'd be comparing to undefined values, which isn't any better). You might as well write: foo = malloc(0); /* make noise */ Ok, just for having it done: if (foo == (foo = some_val)) .. would be right to check if foo stayed the same. No? No. As far as I know, there is no requirement in the standard that the left side of an inequality be evaluated before the right side; or that there is any need for consistency in order of evaluation. (And even if I'm wrong and the C standard does specify evaluation order, other languages may not; so depending on it would be a bad habit to form.) There is no way to see a 0x800 return from malloc(0) as error. The point is that that value is NOT an error indicator at all. (As discussed elsewhere, it isn't quite standards-compliant; since we always return the same value for malloc(0); but the malloc -did- succeed.) So noone should actually use malloc(0) and check the size_t argument before passing it, I guess. The error was later when they attempted to de-reference the pointer returned from the 'malloc(0)'; not in the allocation itself. BUT, that said, the safest and most portable coding practice would be: // The C standard does not require malloc(0) to return NULL; // but whatever it returns MUST NOT be dereferenced. ptr = ( size == 0 ) ? NULL : malloc( size ) ; -Pat ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FLEX, was Re: Return value of malloc(0)
On Wed, Jun 28, 2006 at 10:40:45PM -0700, Randall Hyde wrote: Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. I seriously doubt seeing the code will do much good. Here's the offending line: YY_INPUT( (yy_current_buffer-yy_ch_buf[number_to_move]), yy_n_chars, num_to_read ); Hopefully, people who use your product give better bug reports. I don't know whether I should laugh or cry. gcc -DfreeBSD -c -o lex.yy.o lex.yy.c and it stops with syntax error before numeric constant. Does your code include all the required header files? This looks like a namespace pollution problem. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FLEX, was Re: Return value of malloc(0)
On Wed, 2006-Jun-28 22:40:45 -0700, Randall Hyde wrote: I seriously doubt seeing the code will do much good. Here's the offending line: YY_INPUT( (yy_current_buffer-yy_ch_buf[number_to_move]), yy_n_chars, num_to_read ); How about feeding the C source through the preprocessor, stripping out the #line directives, compiling it and posting the exact gcc error and source context. It may be a gcc bug, it may be a HLA bug or it could be an interaction between the FreeBSD headers and HLA. -- Peter Jeremy pgpp9mRIaGDPu.pgp Description: PGP signature
Re: FLEX, was Re: Return value of malloc(0)
Randall Hyde [EMAIL PROTECTED] BTW, if anyone is intrested in the full FLEX source, it's part of the HLA (High Level Assembler) source package found here: http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip Just wondering if those guys knew that IBM calls their mainframe assembler the High Level Assembler, which they abbreviate HLASM. This isn't an x86 assembler like HLA - it's a z/Architecture (mainframe) assembler, very different beast indeed. But - they may want to pick a new name, lest they incur the wrath of IBM's lawyers. I think IBM took that name in the 80s. Also - it seems that 'webster.cs.ucr.edu' has gone missing from DNS somehow; so I wasn't able to look at the source, although I was able to look at the web pages thanks to Yahoo's cache. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Wed, 28-Jun-2006 at 16:19:35 -0400, Lowell Gilbert wrote:
Andre Albsmeier [EMAIL PROTECTED] writes:
The manpage makes me think that when malloc is called with 0
as argument (and no V-flag had been set) the pointer it returns
can actually be used (as a pointer to the so-called minimal
allocation). It seems, that firefox thinks the same way :-).
However, it is calculated in malloc.c as a constant and is
always 0x800 (on my architecture). Any access to this area
results in a SIGSEV.
The C standard explicitly allows both behaviours, and requires the
implementation to choose one of them. If it returns a non-NULL
pointer, though, that pointer can *only* be used for passing back to
free(). It may *not* be dereferenced. So firefox is wrong, and
actually broken.
Very good. I am glad this is clearly defined.
I assume the behaviour is meant to show up programming errors:
If you use malloc(0) and are crazy enough to access the 'allocated'
memory we give you a SIGSEV to show you how dumb you are :-).
Yes.
In this case the manpage is wrong (or, at least, mis-leading) and
should be fixed (I could give it a try if someone actually is willing
to commit it).
I don't see what you are claiming is wrong. Can you give a brief
It says:
The default behavior is to make a minimal allocation and return
a pointer to it.
This sounds as if it allocated some (!) bytes so the application
can use it. Yes, I know that 0 would be minimal as well :-). And
if you look into malloc.c you will see that, in fact, it doesn't
allocate anything at all:
} else if (!size) {
if (ptr != NULL)
ifree(ptr);
r = ZEROSIZEPTR;
r ist returned later and ZEROSIZEPTR is a constant.
description of you're suggesting.
Hmm, let's see:
The default behavior is to return a non-NULL pointer which may
be passed to free() but does not point to any memory which can
be used by the application.
Apart from that, I suggest, we should run firefox (and maybe other
mozilla apps) with MALLOC_OPTIONS=V.
That would be reasonable, particularly for the time being. However,
the firefox bug really should be fixed in the upstream sources.
In this case, yes, of course.
-Andre
Writing past the end of an allocated buffer (which is what the code
does, if you think about it) is a serious error.
Another position could be that firefox is wrong because it NEVER
may use ANY return value of a malloc(0), regardless of its content.
The C language standard agrees with this position...
--
Micro$oft: When will your system crash today?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
The C Standard says the following about malloc(0): If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. So our default behaviour to crash if a pointer returned by malloc(0) is dereferenced is legal and a good one because it catches errors like the above one. No, our implementation is NOT legal. We always return the SAME value. To be legal, we should not return that value again unless it has been free()-ed. first = malloc(0) ; second = malloc(0) ; if ( first == second ) ERROR( C standards violation ) ; Firefox, or the extension, has a bug in the code. It should not be attempting to de-reference the result of a 'malloc(0)' call. They probably depend on having it return NULL, which is checked elsewhere. (The fix is for them to test for the size == zero case and just set the pointer to NULL instead of calling malloc(0). But that's their problem, not ours.) -Pat ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Johannes Weiner [EMAIL PROTECTED] writes: Hi, On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). They should check the return value of malloc() in any case for successful allocation.. shouldn't they? The value returned from malloc(0) must not be dereferenced whatever it was. It was 0x800, which doesn't count as failure. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: The value returned from malloc(0) must not be dereferenced whatever it was. It was 0x800, which doesn't count as failure. But this would be appropriate for catching the error: if ((foo = malloc(0)) == foo) /* make noise */ wouldn't it? Hannes -- If the telephone rang today, water it! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Johannes Weiner wrote: JWOn Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: JW JW The value returned from malloc(0) must not be dereferenced whatever it JW was. It was 0x800, which doesn't count as failure. JW JWBut this would be appropriate for catching the error: JW JWif ((foo = malloc(0)) == foo) JW /* make noise */ JW JWwouldn't it? Wouldn't it rather invoke undefined behaviour? harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: No, our implementation is NOT legal. We always return the SAME value. To be legal, we should not return that value again unless it has been free()-ed. It is legal due to brain damaged definition of implementation defined behaviour, but it violates the spirit of the standard :-) Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Johannes Weiner [EMAIL PROTECTED] writes: On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: The value returned from malloc(0) must not be dereferenced whatever it was. It was 0x800, which doesn't count as failure. But this would be appropriate for catching the error: if ((foo = malloc(0)) == foo) /* make noise */ wouldn't it? No, sir. Operator precedence: assign first, and then compare, thus the comparison will always be true (else you'd be comparing to undefined values, which isn't any better). You might as well write: foo = malloc(0); /* make noise */ There is no way to see a 0x800 return from malloc(0) as error. -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Matthias Andree wrote: MAJohannes Weiner [EMAIL PROTECTED] writes: MA MA On Thu, Jun 29, 2006 at 06:09:37PM +0200, Matthias Andree wrote: MA MA The value returned from malloc(0) must not be dereferenced whatever it MA was. It was 0x800, which doesn't count as failure. MA MA But this would be appropriate for catching the error: MA MA if ((foo = malloc(0)) == foo) MA/* make noise */ MA MA wouldn't it? MA MANo, sir. Operator precedence: assign first, and then compare, thus the MAcomparison will always be true (else you'd be comparing to undefined MAvalues, which isn't any better). You might as well write: Operator precedence is just for parsing, not for evaluation. The compiler may well first evaluate the foo on the right side of the == (by fetching it) and then go an call malloc and assign foo. It is actually undefined behaviour, I think, so it may well make explode your near-by atom power plant. harti MA MA foo = malloc(0); MA /* make noise */ MA MAThere is no way to see a 0x800 return from malloc(0) as error. MA MA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: The C Standard says the following about malloc(0): If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. So our default behaviour to crash if a pointer returned by malloc(0) is dereferenced is legal and a good one because it catches errors like the above one. No, our implementation is NOT legal. We always return the SAME value. To be legal, we should not return that value again unless it has been free()-ed. first = malloc(0) ; second = malloc(0) ; if ( first == second ) ERROR( C standards violation ) ; Almost. The test should be if ( first != NULL first == second) ERROR( C standards violation ) ; It is after all legal for malloc(0) to return NULL. Otherwise you are correct. Having malloc(0) always returning the same (non-NULL) value is not legal according to the C standard. C99 says: 7.20.3 Memory management functions [...] Each such allocation shall yield a pointer to an object disjoint from any other object. [...] If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. Firefox, or the extension, has a bug in the code. It should not be attempting to de-reference the result of a 'malloc(0)' call. They probably depend on having it return NULL, which is checked elsewhere. (The fix is for them to test for the size == zero case and just set the pointer to NULL instead of calling malloc(0). But that's their problem, not ours.) -Pat ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: No, our implementation is NOT legal. We always return the SAME value. To be legal, we should not return that value again unless it has been free()-ed. It is legal due to brain damaged definition of implementation defined behaviour, but it violates the spirit of the standard :-) Perhaps I'm misunderstanding the 'implementation defined behavior' choices in the standard. I thought that it could either 1) Return NULL; or 2) Behave as though it returned a 'minimum allocation' (which cannot be legally de-referenced). But if it did actually perform a 'minimum allocation'; wouldn't it have to return a different value every time to maintain the free() semantics? -Pat ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Pat Lashley [EMAIL PROTECTED] writes: On Thu, Jun 29, 2006 at 11:44:23AM -0400, Pat Lashley wrote: No, our implementation is NOT legal. We always return the SAME value. To be legal, we should not return that value again unless it has been free()-ed. It is legal due to brain damaged definition of implementation defined behaviour, but it violates the spirit of the standard :-) Perhaps I'm misunderstanding the 'implementation defined behavior' choices in the standard. I thought that it could either 1) Return NULL; or 2) Behave as though it returned a 'minimum allocation' (which cannot be legally de-referenced). I went wandering through the C Working Group archives for the heck of it, and apparently a lot of people were confused over this, thinking either as you did or that unique meant it would a value unique to the usage of malloc(0). It's been clarified recently (and will be in the next revision of the standard) to the meaning you understood. Specifically: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. But if it did actually perform a minimum allocation'; wouldn't it have to return a different value every time to maintain the free() semantics? I think that's another way of looking at the same confusion. If minimum is zero, then using a sentinel value (as in FreeBSD) works. Our malloc() could be easily fixed to be standards-compliant by removing the special handling for ZEROSIZEPTR in malloc.c; then allocations of 0 bytes will be rounded up to 16, just like all other alloations of less than 16 bytes. However, that would lose much of the bug-finding advantage of the current behaviour. This is wandering into -standards territory, though. In any case, the answer to thread's original question is mozilla should fix its code to not assume malloc(0)==NULL. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FLEX, was Re: Return value of malloc(0)
-Original Message- How about feeding the C source through the preprocessor, stripping out the #line directives, compiling it and posting the exact gcc error and source context. Okay, I'll try that when I get home. But I was kind of under the impression that *GCC* runs the preprocessor on the input, during compilation :-). It may be a gcc bug, it may be a HLA bug or it could be an interaction between the FreeBSD headers and HLA. None of the code listed has *anything* to do with the HLA.FLX source (and certainly nothing to do with the rest of the HLA source code). It is quite possible that some FreeBSD headers conflict with this section of the FLEX output (remember, this is *canned* output code from FLEX, this is not generated in response to any FLEX input code). That's why my original question was so generic and not specific -- this would appear to be a generic problem with using FLEX output under BSD and I thought a quick question would affirm/deny that thought. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FLEX, was Re: Return value of malloc(0)
-Original Message- From: Thomas David Rivers [EMAIL PROTECTED] Sent: Jun 29, 2006 3:17 AM To: freebsd-hackers@freebsd.org, [EMAIL PROTECTED] Subject: Re: FLEX, was Re: Return value of malloc(0) Randall Hyde [EMAIL PROTECTED] BTW, if anyone is intrested in the full FLEX source, it's part of the HLA (High Level Assembler) source package found here: http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip Just wondering if those guys knew that IBM calls their mainframe assembler the High Level Assembler, which they abbreviate HLASM. These guys would be just me, and I'm quite aware of HLASM. Of course, the term High Level Assembler predated IBM's HLASM by many years (indeed, the phrase was used a bit in the late 1960s, see Salomon's book for details). This isn't an x86 assembler like HLA - it's a z/Architecture (mainframe) assembler, very different beast indeed. Yes, their concept of High Level meant fancy macro facilities. Not back for a 1980's-era assembler. But - they may want to pick a new name, lest they incur the wrath of IBM's lawyers. I think IBM took that name in the 80s. Again, the generic term High Level Assembler predated HLASM, and HLA and HLASM are two different things. Further, there was an HLA for the Amiga some time back. Again, it's not like this term is terribly original. And I seriously doubt if IBM really cares at this point. Also - it seems that 'webster.cs.ucr.edu' has gone missing from DNS somehow; so I wasn't able to look at the source, although I was able to look at the web pages thanks to Yahoo's cache. Hmmm... Webster is a relatively famous site, so that's unusual. Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Thu, 29 Jun 2006, Harti Brandt wrote: Operator precedence is just for parsing, not for evaluation. The compiler may well first evaluate the foo on the right side of the == (by fetching it) and then go an call malloc and assign foo. Right, thanks for reminding me. I don't usually write code that depends on evaluation order... except with the short-circuiting stuff || or . splint 3.1.1 complains about this issue BTW, but neither GCC 4.1.0 nor ICC 8.1.028 on Linux nor FreeBSD lint complain. I used gcc -Wall which is specified to include -Wsequence-point... It is actually undefined behaviour, I think, so it may well make explode your near-by atom power plant. It had better not... -- Matthias Andree ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Hi, On Thu, Jun 29, 2006 at 07:29:16PM +0200, Matthias Andree wrote: No, sir. Operator precedence: assign first, and then compare, thus the comparison will always be true (else you'd be comparing to undefined values, which isn't any better). You might as well write: foo = malloc(0); /* make noise */ Ok, just for having it done: if (foo == (foo = some_val)) .. would be right to check if foo stayed the same. No? There is no way to see a 0x800 return from malloc(0) as error. So noone should actually use malloc(0) and check the size_t argument before passing it, I guess. Hannes -- One must still have chaos in oneself to be able to give a birth to a dancing star. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Return value of malloc(0)
There is a nice extension for firefox called prefbar. However, newer versions of prefbar (=3.3) make firefox die with SIGSEGV, see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details. The crash happens in libgklayout.so: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100116)] 0x29a9599b in nsGlobalWindow::RunTimeout (this=0x8393500, aTimeout=0x8935000) at nsGlobalWindow.cpp:6378 6378 timeout-mArgv[timeout-mArgc] = Current language: auto; currently c++ (gdb) p timeout-mArgc $1 = 0 (gdb) p timeout-mArgv $2 = (jsval *) 0x800 (gdb) p timeout-mArgv[timeout-mArgc] Error accessing memory address 0x800: Bad address. The 0x800 are the result of an earlier malloc(0). When looking at the MALLOC(3) manpage, we can read (near the description of the flags): ... VAttempting to allocate zero bytes will return a NULL pointer instead of a valid pointer. (The default behavior is to make a minimal allocation and return a pointer to it.) This option is provided for System V compatibility. This option is incompatible with the ``X'' option. ... So I gave it a try by running MALLOC_OPTIONS=V firefox and firefox didn't crash anymore and prefbar was running :-). (Now malloc returns NULL and firefox doesn't interpret the result as a pointer to some allocated memory and therefore doesn't use it). The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. I assume the behaviour is meant to show up programming errors: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. Opinions, please... -Andre P.S.: If someone wants to know where the crash happens in firefox please see http://bugzilla.mozdev.org/show_bug.cgi?id=13809. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Andre Albsmeier [EMAIL PROTECTED] writes: The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. The C standard explicitly allows both behaviours, and requires the implementation to choose one of them. If it returns a non-NULL pointer, though, that pointer can *only* be used for passing back to free(). It may *not* be dereferenced. So firefox is wrong, and actually broken. I assume the behaviour is meant to show up programming errors: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). Yes. In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). I don't see what you are claiming is wrong. Can you give a brief description of you're suggesting. Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. That would be reasonable, particularly for the time being. However, the firefox bug really should be fixed in the upstream sources. Writing past the end of an allocated buffer (which is what the code does, if you think about it) is a serious error. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. The C language standard agrees with this position... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: There is a nice extension for firefox called prefbar. However, newer versions of prefbar (=3.3) make firefox die with SIGSEGV, see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details. The crash happens in libgklayout.so: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100116)] 0x29a9599b in nsGlobalWindow::RunTimeout (this=0x8393500, aTimeout=0x8935000) at nsGlobalWindow.cpp:6378 6378 timeout-mArgv[timeout-mArgc] = Current language: auto; currently c++ (gdb) p timeout-mArgc $1 = 0 (gdb) p timeout-mArgv $2 = (jsval *) 0x800 (gdb) p timeout-mArgv[timeout-mArgc] Error accessing memory address 0x800: Bad address. The 0x800 are the result of an earlier malloc(0). When looking at the MALLOC(3) manpage, we can read (near the description of the flags): ... VAttempting to allocate zero bytes will return a NULL pointer instead of a valid pointer. (The default behavior is to make a minimal allocation and return a pointer to it.) This option is provided for System V compatibility. This option is incompatible with the ``X'' option. ... So I gave it a try by running MALLOC_OPTIONS=V firefox and firefox didn't crash anymore and prefbar was running :-). (Now malloc returns NULL and firefox doesn't interpret the result as a pointer to some allocated memory and therefore doesn't use it). The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. I assume the behaviour is meant to show up programming errors: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. Opinions, please... The C Standard says the following about malloc(0): If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. So our default behaviour to crash if a pointer returned by malloc(0) is dereferenced is legal and a good one because it catches errors like the above one. I agree that the wording in the man page should be improved. Probably it should say that malloc(0) returns a non-NULL pointer which must not be dereferenced without mentioning a minimal allocation. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: (Now malloc returns NULL and firefox doesn't interpret the result as a pointer to some allocated memory and therefore doesn't use it). Return NULL for malloc(0) is one of two possible implementations. The other behaviour is to generate a unique pointer for each call. Both behaviours are intentionally allowed by the standard and code making assumptions about either is broken. It should be added that returning NULL for malloc(0) is consistent with realloc, so it is actually nicer. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Hi All, I'm trying to port my compiler from Linux to freeBSD. It looked like a simple job up to the point I ran my flex code through FLEX on freeBSD. When GCC processes lex.yy.c I get a complaint about an illegal numeric constant in yy_get_next_buffer, which is all FLEX generated (or prewritten) code. The thing compiler just fine under Linux. Any ideas? Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Wed, Jun 28, 2006 at 06:41:05PM -0700, Randall Hyde wrote: Hi All, I'm trying to port my compiler from Linux to freeBSD. It looked like a simple job up to the point I ran my flex code through FLEX on freeBSD. When GCC processes lex.yy.c I get a complaint about an illegal numeric constant in yy_get_next_buffer, which is all FLEX generated (or prewritten) code. The thing compiler just fine under Linux. Any ideas? Cheers, Randy Hyde Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
- Original Message - From: Steve Kargl [EMAIL PROTECTED] To: Randall Hyde [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org Sent: Wednesday, June 28, 2006 10:10 PM Subject: Re: Return value of malloc(0) On Wed, Jun 28, 2006 at 06:41:05PM -0700, Randall Hyde wrote: Hi All, I'm trying to port my compiler from Linux to freeBSD. It looked like a simple job up to the point I ran my flex code through FLEX on freeBSD. When GCC processes lex.yy.c I get a complaint about an illegal numeric constant in yy_get_next_buffer, which is all FLEX generated (or prewritten) code. The thing compiler just fine under Linux. Any ideas? Cheers, Randy Hyde Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. A new thread with a proper subject would be appropriate too :) -- Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FLEX, was Re: Return value of malloc(0)
Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. I seriously doubt seeing the code will do much good. Here's the offending line: YY_INPUT( (yy_current_buffer-yy_ch_buf[number_to_move]), yy_n_chars, num_to_read ); This is from static int yy_get_next_buffer() Which is part of the canned code that comes with FLEX. Compiles just fine under Linux. Linux has a slightly newer version of GCC, but I've been compiling this code on Windows (Borland and VC++) as well as Linux for years without a problem (i.e., older versions of GCC). BTW, if anyone is intrested in the full FLEX source, it's part of the HLA (High Level Assembler) source package found here: http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip I compiled the FLEX code with the command line: flex -8 -i hla.flx This works fine, then I compile the GCC output with gcc -DfreeBSD -c -o lex.yy.o lex.yy.c and it stops with syntax error before numeric constant. As this code is in part of the FLEX-supplied C code, I would think that this problem would be independent of my particular flex code. BTW, I've tried using both the FLEX I use on Linux under BSD as well as the BSD-supplied version. I've even taken the FLEX output from freeBSD and compiled it under Linux (it compiles successfully. I'm using GCC 3.3.5 under Linux, 3.4.4 under BSD. Any known problems with 3.4.4 that would cause this? cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Hi, On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). They should check the return value of malloc() in any case for successful allocation.. shouldn't they? -- Quits: JESUS ([EMAIL PROTECTED]): Ping timeout Cyph3r jesus died from my syn's ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
