Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > SSCANF

Reply
Thread Tools

SSCANF

 
 
Mike Wahler
Guest
Posts: n/a
 
      01-03-2006

"Emmanuel Delahaye" <(E-Mail Removed)> wrote in message
news:43bae22d$0$15331$(E-Mail Removed)...
> Mike Wahler a écrit :
>>>char* stringa = "18/2005"

>>
>> "18/2005" is a string literal. Any attempts to modify
>> any of its characters produces undefined behavior.

>
> How would it be modified ? I'm curious. Isn't the first parameter of
> sscanf() a char const * ?


Brain malfunction. Read 'sscanf', saw 'sprintf'.
My apologies.

-Mike


 
Reply With Quote
 
 
 
 
Superfox il Volpone
Guest
Posts: n/a
 
      01-04-2006
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 ?

The second thing if I want to jump one argument is it correct the
behaviour ?
year[5]
sscanf(str_date, "%*s/%4s", year);

and at last, at year will be placed the string terminator ('\0')

Bye & thx all for the help
~ Superfox il Volpone

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      01-04-2006
"Superfox il Volpone" <(E-Mail Removed)> writes:
> Sorry people, what I posted it's part of a more large program and the
> printf with I verified it was wrong


For context, here's the code you posted:

char* stringa = "18/2005"
char mese[3]; char anno[5];
int i_letture;

i_letture = sscanf(stringa, "%2s/%4s", &mese, &anno);
mese[2] = anno[4] = '\0';

Please read <http://cfaj.freeshell.org/google/>.

This also demonstrates why you should always post a small, complete,
compilable program. We can't guess whether the part you didn't post
is what's causing the problem (in this case, it was). What you posted
wasn't even a correct code fragment; the declaration of stringa is
missing a semicolon, an error that the compiler would have caught.
Don't try to re-type your code; copy-and-paste *exactly* what you fed
to the compiler.

> 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 ?


Given, for example,

char anno[5];

the expression "anno", an array name, is implicitly converted (in most
contexts) to a pointer to the array's first element; in this case, the
resulting expression is of type char*. The expression "&anno" yields
the address of the array; the resulting expression is of type
char (*p)[5], i.e., a pointer to an array of 5 chars.

These two expressions are of different types, but they're both
pointers, they both (in some sense) have the same value, and they
*probably* both have the same representation.

Since sscanf() takes a variable number and type(s) of arguments, the
compiler doesn't know what types are expected for the third and fourth
arguments in your call; it just blindly passes in whatever you
specify. It's your job to make sure you call it correctly. Since the
arguments you gave it were (probably) the same size and representation
as the correct arguments, it happened to work. (Passing something of
an incorrect type to sscanf() actually invokes undefined behavior;
working "correctly" is one of the many possible consequences.)

BTW, I believe there are real systems where char* and char (*p)5 would
have different representations, and your sscanf() call would fail.

> The second thing if I want to jump one argument is it correct the
> behaviour ?
> year[5]
> sscanf(str_date, "%*s/%4s", year);
>
> and at last, at year will be placed the string terminator ('\0')


Yes, that should work (assuming the declaration is "char year[5]"
rather than "year[5]").

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      01-04-2006
Chris McDonald <(E-Mail Removed)> wrote:

> Doesn't the prototype of sscanf() promise to *not* modify its first argument?


I would have sworn that my K&R2 at work gave the type of sscanf()'s
first argument as char*, but I see from n869 that either I or K&R2 am
mistaken. Apologies. It still begs the question of how it can modify
a string literal, however.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-04-2006
Christopher Benson-Manica said:

> Chris McDonald <(E-Mail Removed)> wrote:
>
>> Doesn't the prototype of sscanf() promise to *not* modify its first
>> argument?

>
> I would have sworn that my K&R2 at work gave the type of sscanf()'s
> first argument as char*,


It does. It's listed in the errata.

> but I see from n869 that either I or K&R2 am
> mistaken. Apologies. It still begs the question of how it can modify
> a string literal, however.


No, it doesn't beg the question. "To beg the question" means "to assume as
an implicit premise something you are seeking to prove".

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
Robert Harris
Guest
Posts: n/a
 
      01-04-2006
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.
>
> The second thing if I want to jump one argument is it correct the
> behaviour ?
> year[5]
> sscanf(str_date, "%*s/%4s", year);

Yes, if you change your format string to "%*2s/%4s"
>
> and at last, at year will be placed the string terminator ('\0')

mese and year will have been terminated with '\0' in any case.
>
> Bye & thx all for the help
> ~ Superfox il Volpone
>

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      01-04-2006
Robert Harris wrote:
> 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.


<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.
 
Reply With Quote
 
Robert Harris
Guest
Posts: n/a
 
      01-04-2006
Flash Gordon wrote:
> Robert Harris wrote:
>
>> 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.

>
>
> <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.

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
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      01-04-2006
Robert Harris wrote:
> Flash Gordon wrote:
>> Robert Harris wrote:
>>
>>> 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.

>>
>> <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.

> 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 ...'


So it is still of array type when operated on by the & operator.

> 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 the type above is array of whatever. So the type returned by & is
pointer to array of whatever.

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


No, see above.

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

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

markg@markgordon-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@markgordon-lp ~
$ cat tt.c
void foo(char *s)
{
}

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

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

markg@markgordon-lp ~
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
nelu
Guest
Posts: n/a
 
      01-04-2006

Robert Harris wrote:
> 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 ...'

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[].

>
> 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".'

Exactly.
If the operand has type the result has type *type, thus:
char argv[] -> char *arg[]

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

No

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
sscanf feature in C++? Matt C++ 15 10-19-2004 04:36 PM
sscanf and c++! Mike C++ 3 06-09-2004 10:46 AM
endianness and sscanf/sprintf pramod C++ 22 01-06-2004 01:02 PM
Re: %n conversion in sscanf/VC++ 6-solved Anonymous C++ 0 10-30-2003 05:05 PM
Re: Unitialized Memory Read In sscanf() Darrell Grainger C Programming 1 06-24-2003 06:52 PM



Advertisments