min/max in stdlib.h?!
copx
standard?)
I have the following problem: I defined my own min() / max() macros because
my compiler (MinGW) does NOT define them. When I tried to compile my program
with lcc-win32 the compiler complained about macro redefinition, because
min() and max() are defined in lcc's stdlib.h..
So do these macros belong there or not?
Richard Heathfield
> Are the macros min() and max() part of stdlib.h or not? (according to the
> standard?)
No.
> I have the following problem: I defined my own min() / max() macros
> because my compiler (MinGW) does NOT define them. When I tried to compile
> my program with lcc-win32 the compiler complained about macro
> redefinition, because min() and max() are defined in lcc's stdlib.h..
>
> So do these macros belong there or not?
No, they don't. If they are nevertheless placed there by the
implementation, check that you are invoking the implementation in
conforming mode. If so, then you have uncovered a bug in the
implementation.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Ian Collins
Did you invoke the compiler in conforming mode?
--
Ian Collins.
jacob navia
They are not in the standard.
Note that the definition in stdlib.h is:
#ifndef max
#define max(a,b) (((a) > (b)) ? (a) : (b))
#define min(a,b) (((a) < (b)) ? (a) : (b))
#endif
If you define those macros before including stdlib.h
yours will be taken. Besides, the compiler just
emits a warning.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
jacob navia
Please do the same:
#ifndef max
#define ... // your definition
#endif
This will work in lcc and mingw
Ian Collins
> copx wrote:
>> Are the macros min() and max() part of stdlib.h or not? (according to
>> the standard?)
>>
>> I have the following problem: I defined my own min() / max() macros
>> because my compiler (MinGW) does NOT define them. When I tried to
>> compile my program with lcc-win32 the compiler complained about macro
>> redefinition, because min() and max() are defined in lcc's stdlib.h..
>>
>> So do these macros belong there or not?
>>
>>
>>
>
> They are not in the standard.
> Note that the definition in stdlib.h is:
>
> #ifndef max
> #define max(a,b) (((a) > (b)) ? (a) : (b))
> #define min(a,b) (((a) < (b)) ? (a) : (b))
> #endif
>
> If you define those macros before including stdlib.h
> yours will be taken. Besides, the compiler just
> emits a warning.
>
You can't expect punters to mess about with the order of macro
definitions and header inclusions. Or do you expect them to ignore
warnings?
--
Ian Collins.
jacob navia
They go away in conforming mode *now* ...
:-)
Will be in the next release
copx
"Ian Collins" <ian-...@hotmail.com> schrieb im Newsbeitrag
news:5u93i1F...@mid.individual.net...
> copx wrote:
>> Are the macros min() and max() part of stdlib.h or not? (according to the
>> standard?)
>>
>> I have the following problem: I defined my own min() / max() macros
>> because
>> my compiler (MinGW) does NOT define them. When I tried to compile my
>> program
>> with lcc-win32 the compiler complained about macro redefinition, because
>> min() and max() are defined in lcc's stdlib.h..
>>
>> So do these macros belong there or not?
>>
> No.
Ok, thanks.
> Did you invoke the compiler in conforming mode?
Yes, it did.
Richard Heathfield
> "Ian Collins" <ian-...@hotmail.com> schrieb im Newsbeitrag
> news:5u93i1F...@mid.individual.net...
>
>> Did you invoke the compiler in conforming mode?
>
> Yes, it did.
If you invoked the implementation in its conforming mode and it defined min
and max in stdlib.h, it doesn't really *have* a conforming mode.
Flash Gordon
<snip min/max being defined in stdlib.h even in conforming mode>
> They go away in conforming mode *now* ...
>
> :-)
>
> Will be in the next release
Perhaps rather that fixing these things one at a time when people
complain you should review all of your standard headers and make sure
than in conforming mode they define what the standard requires and
nothing more (at least, nothing more that is not in your namespace as
implementer, you can still define __ya_bo_sucks_to_you if you want).
--
Flash Gordon
Tomás Ó hÉilidhe
> Are the macros min() and max() part of stdlib.h or not? (according to
> the standard?)
If ever in doubt about whether something's Standard C, type it into the
search box on this page:
http://www.dinkumware.com/manuals/default.aspx
It also contains a C++ reference, so be sure also to check that it's
definitely supported in C, and not just in C++.
--
Tomás Ó hÉilidhe
CBFalconer
They do not, and illustrate another failure of lcc-win32 to meet
the C standard. Quoting from N869:
7.20 General utilities <stdlib.h>
[#1] The header <stdlib.h> declares five types and several
functions of general utility, and defines several
macros.234)
...
[#3] The macros defined are NULL (described in 7.17);
EXIT_FAILURE
and
EXIT_SUCCESS
which expand to integer constant expressions that may be |
used as the argument to the exit function to return
unsuccessful or successful termination status, respectively,
to the host environment;
RAND_MAX
which expands to an integer constant expression, the value
of which is the maximum value returned by the rand function;
and
MB_CUR_MAX
which expands to a positive integer expression with type |
size_t whose value is the maximum number of bytes in a
multibyte character for the extended character set specified
by the current locale (category LC_CTYPE), and whose value
is never greater than MB_LEN_MAX.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Keith Thompson
> copx wrote:
>> Are the macros min() and max() part of stdlib.h or not? (according
>> to the standard?)
>>
>> I have the following problem: I defined my own min() / max() macros
>> because my compiler (MinGW) does NOT define them. When I tried to
>> compile my program with lcc-win32 the compiler complained about
>> macro redefinition, because min() and max() are defined in lcc's
>> stdlib.h..
>>
>> So do these macros belong there or not?
>
> They are not in the standard.
> Note that the definition in stdlib.h is:
>
> #ifndef max
> #define max(a,b) (((a) > (b)) ? (a) : (b))
> #define min(a,b) (((a) < (b)) ? (a) : (b))
> #endif
>
> If you define those macros before including stdlib.h
> yours will be taken. Besides, the compiler just
> emits a warning.
I saw your later response in which you said that this is corrected in
the next release.
If the warning were the only effect, then this would not be a
conformance issue (though it would be a QoI issue). But consider the
following strictly conforming program:
#include <stdlib.h>
int max(int a, int b)
{
return a > b ? a : b;
}
int main(void)
{
int n = max(0, 1);
return 0;
}
I don't have lcc-win, but my compiler (when I replace the "#include
<stdlib.h>" with your definition of max) chokes on the function
declaration; I presume lcc-win does as well.
If you wanted to provide min and max macros, I would *strongly*
recommend (a) calling them MIN and MAX, to emphasize that they're
macros and may evaluate their arguments more than once, and (b) define
them in an implementation-specific header, not in a language-defined
header.
There's probably existing code that depends on the current behavior --
but such code is already not portable to other implementations,
possibly without the author's knowledge.
In my opinion, an implementation should *never* define extra stuff in
the standard headers, even conditionally. (Yes, POSIX does this; I'm
not pleased about that either.)
--
Keith Thompson (The_Other_Keith) <ks...@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
SM Ryan
# Are the macros min() and max() part of stdlib.h or not? (according to the
# standard?)
#
# I have the following problem: I defined my own min() / max() macros because
# my compiler (MinGW) does NOT define them. When I tried to compile my program
# with lcc-win32 the compiler complained about macro redefinition, because
# min() and max() are defined in lcc's stdlib.h..
#
# So do these macros belong there or not?
If the header is using #define, you can check with #if(n)def
and rid a previous definition without warning with #undef.
It's likely easier to adapt than try to change the library.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
She broke your heart and inadvertently drove men to deviant lifestyles.
Serve Lau
"Keith Thompson" <ks...@mib.org> schreef in bericht
news:87sl1cy...@kvetch.smov.org...
> In my opinion, an implementation should *never* define extra stuff in
> the standard headers, even conditionally. (Yes, POSIX does this; I'm
> not pleased about that either.)
I'm pretty sure that visual studio defined min and max in stdlib in previous
versions and that is probably why lccwin32 did this too. But I check
msvc2005 now and they apparently changed it to __min and __max. This would
be fine imo.
JimS
It did used to define them, but Microsoft've fixed all that stuff
since about 2001. Plenty of other cranky stuff in there now though ;)
Jim
jacob navia
>
> I'm pretty sure that visual studio defined min and max in stdlib in
> previous versions and that is probably why lccwin32 did this too.
Yes. Since then, Microsoft got more serious about standards.
I did not follow closely what they do now, until you mention it,
and I checked that they changed that, as you say.
Army1987
> "copx" <co...@gazeta.pl> wrote:
> # Are the macros min() and max() part of stdlib.h or not? (according to the
> # standard?)
[snip]
> If the header is using #define, you can check with #if(n)def
> and rid a previous definition without warning with #undef.
> It's likely easier to adapt than try to change the library.
#include <stdio.h>
int max(int a, int b)
{
switch ( (a > b) - (a < b) ) {
case -1: return puts("b is greater");
case 0: return puts("They're equal");
case 1: return puts("a is greater");
}
}
#include <stdlib.h>
int main(void)
{
if ( max(-47, -'/') < 0 )
return EXIT_FAILURE;
else
return EXIT_SUCCESS;
}
doesn't work if stdlib.h contains
#ifdef max
#undef max
#endif
#define max(a, b) (((a) > (b)) ? (a) : (b))
--
Army1987 (Replace "NOSPAM" with "email")
CBFalconer
> SM Ryan wrote:
>
... snip ...
>> It's likely easier to adapt than try to change the library.
>
> #include <stdio.h>
> int max(int a, int b) {
> switch ( (a > b) - (a < b) ) {
> case -1: return puts("b is greater");
> case 0: return puts("They're equal");
> case 1: return puts("a is greater");
> }
> }
>
> doesn't work if stdlib.h contains
Just plain 'doesn't work'. Lookup the return value of puts.
CBFalconer
> "Keith Thompson" <ks...@mib.org> schreef:
>
>> In my opinion, an implementation should *never* define extra
>> stuff in the standard headers, even conditionally. (Yes, POSIX
>> does this; I'm not pleased about that either.)
>
> I'm pretty sure that visual studio defined min and max in stdlib
> in previous versions and that is probably why lccwin32 did this
> too. But I check msvc2005 now and they apparently changed it to
> __min and __max. This would be fine imo.
What Navia and/or Microsoft do has nothing whatsoever to do with
it. Simply read the C standard, or something reasonably close,
such as N869 or N1276.
Harald van Dijk
> Serve Lau wrote:
>> I'm pretty sure that visual studio defined min and max in stdlib in
>> previous versions and that is probably why lccwin32 did this too. But I
>> check msvc2005 now and they apparently changed it to __min and __max.
>> This would be fine imo.
>
> What Navia and/or Microsoft do has nothing whatsoever to do with it.
What jacob navia and Microsoft do has everything to do with whether their
implementations conform to the C standard.
CBFalconer
We are in agreement. :-)
Ben Bacarisse
> Army1987 wrote:
>> SM Ryan wrote:
>>
> ... snip ...
>>> It's likely easier to adapt than try to change the library.
>>
>> #include <stdio.h>
>> int max(int a, int b) {
>> switch ( (a > b) - (a < b) ) {
>> case -1: return puts("b is greater");
>> case 0: return puts("They're equal");
>> case 1: return puts("a is greater");
>> }
>> }
> ... snip ...
>>
>> doesn't work if stdlib.h contains
> anything at all.
>
> Just plain 'doesn't work'. Lookup the return value of puts.
It works fine. I think you missed the point of the example (now lost
since you snipped the key part).
--
Ben.
Serve Lau
"CBFalconer" <cbfal...@yahoo.com> schreef in bericht
news:478101B0...@yahoo.com...
>> I'm pretty sure that visual studio defined min and max in stdlib
>> in previous versions and that is probably why lccwin32 did this
>> too. But I check msvc2005 now and they apparently changed it to
>> __min and __max. This would be fine imo.
>
> What Navia and/or Microsoft do has nothing whatsoever to do with
> it. Simply read the C standard, or something reasonably close,
> such as N869 or N1276.
lccwin32 follows msvc as a windows development tool. If microsoft followed
the C standard back in 1998 when they introduced msvc6, lccwin32 wouldnt
have had min and max in stdlib either.
They should have followed the standard yes, but lccwin32 tries to have
software compatible with microsoft's tools above all (correct me if I'm
wrong) It isnt so strange for a windows compiler (lccwin32) to follow the
most used windows development tool for C in the world (msvc)
jacob navia
Well that is exactly the position I had. I tried to be compatible with
what Microsoft said.
I remember when I started writing those headers, and my frame of mind at
that time wasn't really a "language lawyer" mindset. I saw it in the
stdlib.h from msvc 4.1 (if I remember correctly) I said myself that
those are useful macros, I put them there, and there they stayed
until now. This user has seen this problem, and I thank him
for this bug report.
The "regulars" now will start turning this bug around for decades
(like Mr Heathfield that said that lcc-win did not have a conforming
mode because of this bug) but this is just BORING polemic guys.
You will have to find something more substantial to go on.
Anyway I will put the correction this evening so they will not
have so much time to go on...
:-)
CBFalconer
>
... snip ...
>
> Well that is exactly the position I had. I tried to be compatible
> with what Microsoft said.
>
> I remember when I started writing those headers, and my frame of
> mind at that time wasn't really a "language lawyer" mindset. I saw
> it in the stdlib.h from msvc 4.1 (if I remember correctly) I said
> myself that those are useful macros, I put them there, and there
> they stayed until now. This user has seen this problem, and I
> thank him for this bug report.
You forgot to add that you disovered c.l.c and have become more
alert to what the standard says. That would have been much more
useful than what you did say.
CBFalconer
I don't think there is any argument that "max(a, b)" should return
one of the values a or b. However the above returns the return
from puts, which is (from N869):
7.19.7.10 The puts function
Synopsis
[#1]
#include <stdio.h>
int puts(const char *s);
Description
[#2] The puts function writes the string pointed to by s to
the stream pointed to by stdout, and appends a new-line
character to the output. The terminating null character is
not written.
Returns
[#3] The puts function returns EOF if a write error occurs;
otherwise it returns a nonnegative value.
Flash Gordon
> Ben Bacarisse wrote:
>> CBFalconer <cbfal...@yahoo.com> writes:
>>> Army1987 wrote:
>>>> SM Ryan wrote:
>>>>
>>> ... snip ...
>>>>> It's likely easier to adapt than try to change the library.
>>>> #include <stdio.h>
>>>> int max(int a, int b) {
>>>> switch ( (a > b) - (a < b) ) {
>>>> case -1: return puts("b is greater");
>>>> case 0: return puts("They're equal");
>>>> case 1: return puts("a is greater");
>>>> }
>>>> }
>>> ... snip ...
>>>> doesn't work if stdlib.h contains
>>> anything at all.
>>>
>>> Just plain 'doesn't work'. Lookup the return value of puts.
>> It works fine. I think you missed the point of the example (now
>> lost since you snipped the key part).
>
> I don't think there is any argument that "max(a, b)" should return
> one of the values a or b.
<snip irrelevant material>
Yes there is. The one Ben wrote should *not* return either a or b. The
entire point was that the behaviour would be different if stdlib.h
defines max.
--
Flash Gordon
Ben Bacarisse
> Ben Bacarisse wrote:
>> CBFalconer <cbfal...@yahoo.com> writes:
>>> Army1987 wrote:
>>>> SM Ryan wrote:
>>>>
>>> ... snip ...
>>>>> It's likely easier to adapt than try to change the library.
>>>>
>>>> #include <stdio.h>
>>>> int max(int a, int b) {
>>>> switch ( (a > b) - (a < b) ) {
>>>> case -1: return puts("b is greater");
>>>> case 0: return puts("They're equal");
>>>> case 1: return puts("a is greater");
>>>> }
>>>> }
>>> ... snip ...
>>>>
>>>> doesn't work if stdlib.h contains
>>> anything at all.
>>>
>>> Just plain 'doesn't work'. Lookup the return value of puts.
>>
>> It works fine. I think you missed the point of the example (now
>> lost since you snipped the key part).
>
> I don't think there is any argument that "max(a, b)" should return
> one of the values a or b.
max(a, b) can return whatever that author wants it to. The example
was intended to show that it matters where and when macros are
defined.
> from puts, which is (from N869):
Yes, I know what puts returns and I am sure Army1987 does too. The
same point could have been made using
int max(int a, int b) { return 42; }
or
int max(int a, int b) { puts("In my own max."); return a > b ? a : b; }
--
Ben.
Ben Bacarisse
It was Army1987 not me. I just "stepped up" when the example was
misinterpreted.
--
Ben.
Flash Gordon
> Flash Gordon <sp...@flash-gordon.me.uk> writes:
>
>> CBFalconer wrote, On 06/01/08 22:31:
>>> Ben Bacarisse wrote:
>>>> CBFalconer <cbfal...@yahoo.com> writes:
>>>>> Army1987 wrote:
<snip>
>> Yes there is. The one Ben wrote should *not* return either a or b. The
>> entire point was that the behaviour would be different if stdlib.h
>> defines max.
>
> It was Army1987 not me. I just "stepped up" when the example was
> misinterpreted.
Sorry, I didn't look far enough in to the quoting.
--
Flash Gordon
CBFalconer
One thing is sure - that I regret having pointed anything out about
it, The resultant furor is not worth the <paper> it is written on.
:-)
David Thompson
wrote:
<snip>
> What Navia and/or Microsoft do has nothing whatsoever to do with
> it. Simply read the C standard, or something reasonably close,
> such as N869 or N1276.
>
- formerly david.thompson1 || achar(64) || worldnet.att.net
CBFalconer
> CBFalconer <cbfal...@yahoo.com> wrote:
> <snip>
>> What Navia and/or Microsoft do has nothing whatsoever to do with
>> it. Simply read the C standard, or something reasonably close,
>> such as N869 or N1276.
>
> N1256 .
Which doesn't have a greppable (etc.) text version, which N869
does. In fact you can get N869.txt compressed to about 85k bytes
from my site, as N869_txt.bz2.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
santosh
> David Thompson wrote:
>> CBFalconer <cbfal...@yahoo.com> wrote:
>> <snip>
>>> What Navia and/or Microsoft do has nothing whatsoever to do with
>>> it. Simply read the C standard, or something reasonably close,
>>> such as N869 or N1276.
>>
>> N1256 .
>
> Which doesn't have a greppable (etc.) text version, which N869
> does. In fact you can get N869.txt compressed to about 85k bytes
> from my site, as N869_txt.bz2.
You can convert n1256.pdf to a horrid, poorly formatted text file using
many easily available utilities which you can then "grep" to find the
relevant sections and go to them directly in the PDF file.
But personally I find that search has improved significantly on recent
versions of Adobe's PDF reader.
CBFalconer
But, surprise, I can avoid all that nonsense by simply using the
pre-formatted and relatively compact N869.txt. It can be read with
less, searched with grep, etc. etc. etc. I don't even need any
monstrous oversized .pdf readers to access it. I can even cut and
paste.
Martin Ambuhl
> But, surprise, I can avoid all that nonsense by simply using the
> pre-formatted and relatively compact N869.txt. It can be read with
> less, searched with grep, etc. etc. etc. I don't even need any
> monstrous oversized .pdf readers to access it. I can even cut and
> paste.
<ot>
You might find the not-monstrous-oversized ghostview a reasonable choice
for reading .pdf files. Not only is the footprint much smaller, but
files load much faster.
</ot>
Randy Howard
(in article <4797E3D3...@yahoo.com>):
> Martin Ambuhl wrote:
>> CBFalconer wrote:
>>
>>> But, surprise, I can avoid all that nonsense by simply using the
>>> pre-formatted and relatively compact N869.txt. It can be read
>>> with less, searched with grep, etc. etc. etc. I don't even need
>>> any monstrous oversized .pdf readers to access it. I can even
>>> cut and paste.
>>
>> <ot>
>> You might find the not-monstrous-oversized ghostview a reasonable
>> choice for reading .pdf files. Not only is the footprint much
>> smaller, but files load much faster.
>> </ot>
>
> Is is smaller than more.com (mine)? or list, or less. Can it be
> searched with grep.
>
> more.com Oct 18 1988 435
> list.com Jan 22 2004 28211
> less.exe Apr 5 2002 204800
> grep.exe Aug 12 2007 84240
Sure an old fart like yourself can afford a system by now with more
than 1MB of RAM. :P
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Martin Ambuhl
> Martin Ambuhl wrote:
>> CBFalconer wrote:
>>
>>> But, surprise, I can avoid all that nonsense by simply using the
>>> pre-formatted and relatively compact N869.txt. It can be read
>>> with less, searched with grep, etc. etc. etc. I don't even need
>>> any monstrous oversized .pdf readers to access it. I can even
>>> cut and paste.
>> <ot>
>> You might find the not-monstrous-oversized ghostview a reasonable
>> choice for reading .pdf files. Not only is the footprint much
>> smaller, but files load much faster.
>> </ot>
>
> Is is smaller than more.com (mine)? or list, or less. Can it be
> searched with grep.
I never made any statement to which that is an appropriate response.
CBFalconer
> CBFalconer wrote:
> >
... snip ...
>>
>>> You might find the not-monstrous-oversized ghostview a reasonable
>>> choice for reading .pdf files. Not only is the footprint much
>>> smaller, but files load much faster.
>>> </ot>
>>
>> Is is smaller than more.com (mine)? or list, or less. Can it be
>> searched with grep.
>
> I never made any statement to which that is an appropriate response.
"not-monstrous-oversized" ?