SSCANF

[Robert Harris]

Re: SSCANF

Superfox il Volpone wrote:[color=blue]
> Sorry people, what I posted it's part of a more large program and the
> printf with I verified it was wrong :)
>
> I solved but I don't understand one thing :
> the sscanf works with '&mese' and 'mese' in the correct manner : maybe
> it's the compiler (GCC) that does some correction ?[/color]
No. If mese is an array, then mese and &mese are the same thing.[color=blue]
>
> The second thing if I want to jump one argument is it correct the
> behaviour ?
> year[5]
> sscanf(str_date , "%*s/%4s", year);[/color]
Yes, if you change your format string to "%*2s/%4s"[color=blue]
>
> and at last, at year will be placed the string terminator ('\0')[/color]
mese and year will have been terminated with '\0' in any case.[color=blue]
>
> Bye & thx all for the help
> ~ Superfox il Volpone :)
>[/color]

[Flash Gordon]

Re: SSCANF

Robert Harris wrote:[color=blue]
> Superfox il Volpone wrote:[color=green]
>> Sorry people, what I posted it's part of a more large program and the
>> printf with I verified it was wrong :)
>>
>> I solved but I don't understand one thing :
>> the sscanf works with '&mese' and 'mese' in the correct manner : maybe
>> it's the compiler (GCC) that does some correction ?[/color]
> No. If mese is an array, then mese and &mese are the same thing.[/color]

<snip>

No they are not, they have different types. As a result of this, passing
the wrong one as one of the varidac parameters to sscanf *could* cause
it to fail, although I'm not aware of any implementations on which it
would. The failure could occur if pointer to array of char used a
different representation to pointer to char (say, an implementation
encoded the size of the array in pointer to array of char but not in
pointer to char). It will also cause the compiler to complain at you if
you pass a pointer to array of char to a function expecting a pointer to
char.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Robert Harris]

Re: SSCANF

Flash Gordon wrote:[color=blue]
> Robert Harris wrote:
>[color=green]
>> Superfox il Volpone wrote:
>>[color=darkred]
>>> Sorry people, what I posted it's part of a more large program and the
>>> printf with I verified it was wrong :)
>>>
>>> I solved but I don't understand one thing :
>>> the sscanf works with '&mese' and 'mese' in the correct manner : maybe
>>> it's the compiler (GCC) that does some correction ?[/color]
>>
>> No. If mese is an array, then mese and &mese are the same thing.[/color]
>
>
> <snip>
>
> No they are not, they have different types. As a result of this, passing
> the wrong one as one of the varidac parameters to sscanf *could* cause
> it to fail, although I'm not aware of any implementations on which it
> would. The failure could occur if pointer to array of char used a
> different representation to pointer to char (say, an implementation
> encoded the size of the array in pointer to array of char but not in
> pointer to char). It will also cause the compiler to complain at you if
> you pass a pointer to array of char to a function expecting a pointer to
> char.[/color]
Yes they are. For the array mese passed as a parameter, paragraph
6.3.2.1 of the C standard applies, and I quote:

'Except when it is used as an operand of the sizeof operator or the
unary & operator, or is a string literal used to initialize an array, an
expression that has type "array of type" is convered to an expression
with type "pointer to type" that points to the initial element of the
array object ...'

While for &mese passed as a parameter, paragraph 6.5.3.2 applies:

'The unary & operation returns the address of its operand. If the
operand has type "type", the result has type "pointer to type".'

So they are the same (in the context of being passed as parameters to a
function).

Robert

[Flash Gordon]

Re: SSCANF

Robert Harris wrote:[color=blue]
> Flash Gordon wrote:[color=green]
>> Robert Harris wrote:
>>[color=darkred]
>>> Superfox il Volpone wrote:
>>>
>>>> Sorry people, what I posted it's part of a more large program and the
>>>> printf with I verified it was wrong :)
>>>>
>>>> I solved but I don't understand one thing :
>>>> the sscanf works with '&mese' and 'mese' in the correct manner : maybe
>>>> it's the compiler (GCC) that does some correction ?
>>>
>>> No. If mese is an array, then mese and &mese are the same thing.[/color]
>>
>> <snip>
>>
>> No they are not, they have different types. As a result of this,
>> passing the wrong one as one of the varidac parameters to sscanf
>> *could* cause it to fail, although I'm not aware of any
>> implementations on which it would. The failure could occur if pointer
>> to array of char used a different representation to pointer to char
>> (say, an implementation encoded the size of the array in pointer to
>> array of char but not in pointer to char). It will also cause the
>> compiler to complain at you if you pass a pointer to array of char to
>> a function expecting a pointer to char.[/color]
> Yes they are. For the array mese passed as a parameter, paragraph
> 6.3.2.1 of the C standard applies, and I quote:
>
> 'Except when it is used as an operand of the sizeof operator or the
> unary & operator, or is a string literal used to initialize an array, an[/color]
^^^^^^^^^^^^^^^ ^[color=blue]
> expression that has type "array of type" is convered to an expression
> with type "pointer to type" that points to the initial element of the
> array object ...'[/color]

So it is still of array type when operated on by the & operator.
[color=blue]
> While for &mese passed as a parameter, paragraph 6.5.3.2 applies:
>
> 'The unary & operation returns the address of its operand. If the
> operand has type "type", the result has type "pointer to type".'[/color]

So the type above is array of whatever. So the type returned by & is
pointer to array of whatever.
[color=blue]
> So they are the same (in the context of being passed as parameters to a
> function).[/color]

No, see above.

The addresses are the same, but the types are not. So, for example, we
get from gcc:
markg@markgordo n-lp ~
$ cat t.c
void foo(char *s)
{
}

int main(void)
{
char fred[10];
foo(fred);
foo(&fred);
}

markg@markgordo n-lp ~
$ gcc -ansi -pedantic -O t.c
t.c: In function `main':
t.c:9: warning: passing arg 1 of `foo' from incompatible pointer type

markg@markgordo n-lp ~
$ cat tt.c
void foo(char *s)
{
}

int main(void)
{
char fred[10];
foo(fred);
/* foo(&fred); */
}

markg@markgordo n-lp ~
$ gcc -ansi -pedantic -O tt.c

markg@markgordo n-lp ~
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[nelu]

Re: SSCANF


Robert Harris wrote:[color=blue]
> Yes they are. For the array mese passed as a parameter, paragraph
> 6.3.2.1 of the C standard applies, and I quote:
>
> 'Except when it is used as an operand of the sizeof operator or the
> unary & operator, or is a string literal used to initialize an array, an
> expression that has type "array of type" is convered to an expression
> with type "pointer to type" that points to the initial element of the
> array object ...'[/color]
meaning
char *var
and
char var[]
are considered the same in this case. It does not say char var[] is the
same as char *var[].
[color=blue]
>
> While for &mese passed as a parameter, paragraph 6.5.3.2 applies:
>
> 'The unary & operation returns the address of its operand. If the
> operand has type "type", the result has type "pointer to type".'[/color]
Exactly.
If the operand has type the result has type *type, thus:
char argv[] -> char *arg[]
[color=blue]
> So they are the same (in the context of being passed as parameters to a
> function).[/color]
No

[Chris Torek]

Re: SSCANF

In article <djNuf.70590$PD 2.16428@fe1.new s.blueyonder.co .uk>
Robert Harris <robert.f.harri s@blueyonder.co .uk> wrote:[color=blue]
>... If mese is an array, then mese and &mese are the same thing.[/color]

In much the same way that 3 and 3.1415926535897 93 are "the same
thing", i.e., they compare equal when converted to some particular
common type (int, in this case).

The problem is that "&mese" has the wrong type. It is hard to
compare two values of different types (are 3 and 3.14 equal?); the
first step in such a comparison is to choose some additional type
-- perhaps one of the original two, or perhaps a third -- and
convert all the values to the same type, after which they can
finally be compared.

In the case of 3 and 3.14, if the type chosen for comparison is
"int", they are equal. If the type chosen for comparison is
"double", they are not equal. So 3 and 3.14 are equal, and yet
are also not equal.

I use the above example to make it clear that it is not sufficient
to find *a* type under conversion to which comparison shows the
original values as equal: while (int)3 == (int)3.14, I think most
people would say that 3 and 3.14 are *not* equal, and indeed,
(double)3 != (double)3.14.

You would have a much stronger case if you could prove that, for
some large set of C types \elem T, (T)mese == (T)&mese; but I think
this is impossible to prove in "Standard C Virtual Machine", due
to lack of information. (It actually happens to be true on many
real machines, if only because so many real machines have only one
hardware "pointer" type, or at least, only one that is used by C
compilers. The test is more interesting -- not a "degenerate case"
as a mathematician might put it -- when performed on machines with
actual different hardware pointer types, such as a Data General
MV/10000, or a 1960s PR1ME, or some such.)

In any case, Standard C permits an 80x86 C compiler to pass mese
(or &mese[0]) in a register, but put &mese on the stack (or vice
versa), simply because the types differ. If an 80x86 C compiler
did this, calls using the wrong type would in fact fail, even on
the ordinary 80x86. (In this particular case, &mese[0] has type
(char *), but &mese has type (char (*)[5]).)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

Re: SSCANF

Flash Gordon <spam@flash-gordon.me.uk> writes:[color=blue]
> Robert Harris wrote:[color=green]
>> Superfox il Volpone wrote:[color=darkred]
>>> Sorry people, what I posted it's part of a more large program and the
>>> printf with I verified it was wrong :)
>>>
>>> I solved but I don't understand one thing :
>>> the sscanf works with '&mese' and 'mese' in the correct manner : maybe
>>> it's the compiler (GCC) that does some correction ?[/color]
>> No. If mese is an array, then mese and &mese are the same thing.[/color]
>
> <snip>
>
> No they are not, they have different types. As a result of this,
> passing the wrong one as one of the varidac parameters to sscanf
> *could* cause it to fail, although I'm not aware of any
> implementations on which it would. The failure could occur if pointer
> to array of char used a different representation to pointer to char
> (say, an implementation encoded the size of the array in pointer to
> array of char but not in pointer to char). It will also cause the
> compiler to complain at you if you pass a pointer to array of char to
> a function expecting a pointer to char.[/color]

Perhaps more realistically, byte pointers could be bigger than word
pointers. This could happen on a system where native machine
addresses point to words, and the C implementation needs a word
pointer and an offset to refer to a byte within a word. (The C
implementation for Cray vector machines *almost* does this, but it
puts the offset into the otherwise unused high-order bits of the word
pointer, so a pointer to the first byte of a word still happens to
have the same representation as a pointer to the entire word.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Robert Harris]

Re: SSCANF

Flash Gordon wrote:[color=blue]
> Robert Harris wrote:
>
>[color=green][color=darkred]
>>> <snip>
>>>
>>> No they are not, they have different types. As a result of this,
>>> passing the wrong one as one of the varidac parameters to sscanf
>>> *could* cause it to fail, although I'm not aware of any
>>> implementations on which it would. The failure could occur if pointer
>>> to array of char used a different representation to pointer to char
>>> (say, an implementation encoded the size of the array in pointer to
>>> array of char but not in pointer to char). It will also cause the
>>> compiler to complain at you if you pass a pointer to array of char to
>>> a function expecting a pointer to char.[/color]
>>
>> Yes they are. For the array mese passed as a parameter, paragraph
>> 6.3.2.1 of the C standard applies, and I quote:
>>
>> 'Except when it is used as an operand of the sizeof operator or the
>> unary & operator, or is a string literal used to initialize an array, an[/color]
>
> ^^^^^^^^^^^^^^^ ^
>[color=green]
>> expression that has type "array of type" is convered to an expression
>> with type "pointer to type" that points to the initial element of the
>> array object ...'[/color]
>
>
> So it is still of array type when operated on by the & operator.
>[color=green]
>> While for &mese passed as a parameter, paragraph 6.5.3.2 applies:
>>
>> 'The unary & operation returns the address of its operand. If the
>> operand has type "type", the result has type "pointer to type".'[/color]
>
>
> So the type above is array of whatever. So the type returned by & is
> pointer to array of whatever.
>[color=green]
>> So they are the same (in the context of being passed as parameters to
>> a function).[/color]
>
>
> No, see above.
>
> The addresses are the same, but the types are not. So, for example, we
> get from gcc:
> markg@markgordo n-lp ~
> $ cat t.c
> void foo(char *s)
> {
> }
>
> int main(void)
> {
> char fred[10];
> foo(fred);
> foo(&fred);
> }
>
> markg@markgordo n-lp ~
> $ gcc -ansi -pedantic -O t.c
> t.c: In function `main':
> t.c:9: warning: passing arg 1 of `foo' from incompatible pointer type[/color]
Sorry, You're right.

Robert