On Thu, 30 Oct 2003, Garrett Wollman wrote:
On Thu, 30 Oct 2003 12:32:46 +0100 (CET), Harti Brandt [EMAIL PROTECTED] said:
The c89 utility (which specified a compiler for the C Language specified
by the 108 ISO/IEC 9899: 1990 standard) has been replaced by a c99 utility
(which specifies a
Harti Brandt wrote:
Section 7.19.6.7 of N843 states:
Reaching the end of the string is equivalent to encountering end-of-file
for the fscanf function.
OK, I buy this one. 8-).
Unfortunately this is missing in POSIX, but obviously implied by their
reference to ISO.
I don't know if we
On Fri, Oct 31, 2003 at 06:01:34PM +1100, Bruce Evans wrote:
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
int8_t being smaller than
Bruce Evans wrote:
On Thu, 30 Oct 2003, Garrett Wollman wrote:
More specifically: IEEE Std. 1003.1-2001 is aligned to ISO/IEC
9899:1999 in all respects. C99 alignment was one of the principal
reasons for bringing out a whole new standard in the first place,
rather than continuing the
On Fri, 31 Oct 2003, Terry Lambert wrote:
Bruce Evans wrote:
... int8_t is
optional in C99 and all code that uses it unconditionally is unportable.
Similarly for most other types in stdint.h. The required ones are
[u]int_least{8,16,32,64}_t and [u]int_fast{8,16,32,64}_t and
On Fri, 31 Oct 2003 18:01:34 +1100 (EST), Bruce Evans [EMAIL PROTECTED] said:
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
int8_t
On Fri, Oct 31, 2003 at 10:06:43AM -0500, Garrett Wollman wrote:
On Fri, 31 Oct 2003 18:01:34 +1100 (EST), Bruce Evans [EMAIL PROTECTED] said:
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a
On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote:
Perhaps not smaller in terms of the sizeof operator, but why can't one
have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
8 of them - the other 8 being padding?
7.18.1.1 Exact-width integer types
1 The
On Fri, Oct 31, 2003 at 06:20:17PM +0100, Stefan Farfeleder wrote:
On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote:
Perhaps not smaller in terms of the sizeof operator, but why can't one
have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
8 of them - the
Harti Brandt wrote:
TLParagraph 6 of:
TL
TL http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html
TL
TLImplies that the lack of characters in the string following the
TLconversion, due to failure in assignment, should result in an
TLInput failure. Note also that stdio.h
On Thu, 30 Oct 2003, Terry Lambert wrote:
TLHarti Brandt wrote:
TL TLParagraph 6 of:
TL TL
TL TL http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html
TL TL
TL TLImplies that the lack of characters in the string following the
TL TLconversion, due to failure in assignment, should
On Thu, 30 Oct 2003 12:32:46 +0100 (CET), Harti Brandt [EMAIL PROTECTED] said:
The c89 utility (which specified a compiler for the C Language specified
by the 108 ISO/IEC 9899: 1990 standard) has been replaced by a c99 utility
(which specifies a compiler for 109 the C Language specified by the
On Tue, 28 Oct 2003, Terry Lambert wrote:
TLHarti Brandt wrote:
TL When applying %*d%d to the string 123 the first 'd' format matches
TL the string 123 and the conversion yields the number 123. This is then
TL thrown away because assignment is suppressed. The next format specified
TL finds an EOF
(Cc set to current).
On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
JKHBack in the pre-panther timeframe, we received the following bug report:
JKH
JKHEarlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
JKHthe following program:
JKH
JKH#include stdlib.h
JKH
JKHmain()
JKH{ int
On Tue, 28 Oct 2003, Harti Brandt wrote:
(Cc set to current).
On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
JKHBack in the pre-panther timeframe, we received the following bug report:
JKH
JKHEarlier versions of Mac OS X (e.g., 10.2.6) return a value of -1 with
JKHthe following program:
On Tue, 28 Oct 2003, Daniel Eischen wrote:
DEOn Tue, 28 Oct 2003, Harti Brandt wrote:
DE
DE
DE (Cc set to current).
DE
DE On Tue, 28 Oct 2003, Jordan K Hubbard wrote:
DE
DE JKHBack in the pre-panther timeframe, we received the following bug report:
DE JKH
DE JKHEarlier versions of Mac OS X (e.g.,
I think ISO-C is pretty clear here.
It would be wise to raise this on comp.std.c which is read by several
of the ISO C standard authors. Things that seem pretty clear often
turn out not to be...
-- Richard
___
[EMAIL PROTECTED] mailing list
On Tue, Oct 28, 2003 at 04:07:13PM +, Richard Tobin wrote:
I think ISO-C is pretty clear here.
It would be wise to raise this on comp.std.c which is read by several
of the ISO C standard authors. Things that seem pretty clear often
turn out not to be...
This topic is discussed almost
Harti Brandt wrote:
When applying %*d%d to the string 123 the first 'd' format matches
the string 123 and the conversion yields the number 123. This is then
thrown away because assignment is suppressed. The next format specified
finds an EOF condition on the stream so this counts as an input
19 matches
Mail list logo
