memset o/p not correct

[Keith Thompson]

actually it was for doing the following program

/*program to find the maximum matching pattern in the string*/

#include < string.h >
#include < stdio.h >
#include < stdlib.h >

You can't have spaces after the '<' or before the '>' in a #include
directive. My compiler complains that it can't find headers
" string.h ", " stdio.h ", or " stdlib.h ". I'm surprised yours
accepts it, but since the interpretation of header names is
implementation-specific, it's possible. But the correct directives
are:

#include <string.h>
#include <stdio.h>
#include <stdlib.h>

Your article was encoded as "quoted-printable", which means that '='
characters are encoded as "=3D". If you can persuade your newsreaqder
to post plain text rather than quoted-printable, it would be helpful.
Possibly my own newsreader should have done the translation when
saving the file, but there's nothing in what you posted that really
requires anything more elaborate than a plain-text encoding.

void findmaxpat(char*,char*,int*);
void printmaxpat(char*,int*);

int main(void)
{

int i;

You declare ``i'', but you never use it.

Please, please, *PLEASE* indent your code properly. It's much more
difficult to read when everything is shoved over against the left
margin.

It's possible you did indent your code, and your newsreader or
something else killed it. If so, please try to solve that problem.
If you're using tabs for indentation, try using just spaces. And make
sure you're using an editor that's designed to work with source code.

[...]

gets(s);

Never use gets(). Never. See question 12.23 in the comp.lang.c FAQ,
<http://c-faq.com/>. (The FAQ is an excellent resource; reading the
whole thing would not be a waste of your time.)

[...]

(*maxpat == -1)? printf("\"%s\"\n",s) uts(s);

This is an entirely gratuitous use of the conditional operator; it
does nothing but make your code harder to read. Just use an if
statement:

if (*maxpat == -1)
printf("\"%s\"\n",s);
else
puts(s);

Personally, I always use braces, even for a single statement:

if (*maxpat == -1) {
printf("\"%s\"\n",s);
}
else {
puts(s);
}

but that's a fairly minor style point; I recommend it, but feel free
to make your own choice. Using "?:" rather than if/else in a
statement context, on the other hand, is just silly.

if(temp-s == *maxpat)
{
printf("^");
maxpat++;
}
else
printf("%c",' ');
}

puts("");
}

There are two main approaches to writing information to stdout. You
can use printf for everything, which is a simpler approach (as long as
you're careful about '%' characters with the format string). Or you
can make use of the make use of the wider variety of output functions,
such as puts, fputs, putchar, and so forth. Always using printf had
the advantage that there's only one function to learn. But here,
since you're using puts anyway, I'll suggest that the above 3 output
calls could be written as:

putchar('^');
...
putchar(' ');
...
putchar('\n');

 

[Herbert Rosenau]

sorry I forgot to declare i , but still the o/p is same

#include <string.h>
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int maxpat[80],i;
memset(maxpat,-1,80);

<snip>

Check the definition of memset in your reference book, it sets a specified
number of *bytes*. This also means that having corrected the error (sizeof
*maxpat is your friend) it won't be portable to implementations using 1s
complement or sign-magnitude if you can find such an implementation.

Why not? The program will fill maxpat with whatever -1 represents and print
that.

No, it will not - except sizeof char is equal sizeo fint on his
mashine and then it would work perfectly. But the OP shows that on his
mashine is sizeof char < sizeof int, so the program fails miserably as
it shoud.

Perfectly portable

No, perfectly importable as the program requires that sizeof char ==
sizeof int, what is not the case on his implementation wand will not
on mamy other ones too and will occure simply undefined behavior on
others, because the standard allows padding bits in ints and between
bytes, so storing a sequence of (char) (int) -1 is not identical as
storing (int) -i in an array of ints.

memset strores a number of chars into an array of chars and noit as
the OP thinks a number of ints into an array of its. So the program is
completely absolute importable anyway.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

The OP expressed his desire to set all *integers* to -1. Which it will
do if he changed the 80 in the memset to 80*sizeof(int) and the
architecture was 2's complement.

Which will never do! Because
- the array is defined as an array of int.

memset does not handle ints,
- it gets a pointer to char which can not be an array of int
- it gets an single int that gets shorten to an single char to be
stored into a single char
- it gets a number of char that is not a number of ints when sizeof
char is < sizeof int.



--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

Hi,

the following is actually a part of the pattern matching program which
i tried ,memset is not setting the entire integer array with
-1

#include <string.h>
#include <stdio.h>
#include <stdlib.h>

int main(void)
{

int maxpat[80];
memset(maxpat,-1,80);

You're setting 80 bytes. The array is bigger than that (80*sizeof(int)).
Try:

memset(maxpat,-1,sizeof maxpat);

Does even fail on any mashine that uses padding bits because a
sequence of bytes of (char) (int) -1 mut not give the same bitpattern
as (int) -1 as the C standard forbids explicity to store a value of
one type and read of another one:

union {
char c[2];
int i;
} s;

s.c[0] = -1;
s.c[1] = -1;

if (s.i != -1)
/* trap/segfault or whatever the iplementation does on illegal
memory access */

memset handles bytes, not ints. A value of int is not identical with a
sequence of char on some mashines.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

Keith Thompson wrote:

[...]

#define MPSIZE 80
#define VALUE -1
int maxpat[MPSIZE], i;

for (i = 0; i < MPSIZE; i++) maxpat = VALUE;
[...]

Quibble:
#define VALUE (-1)

It doesn't matter in this case, but it's a good habit.
Better still

const int value = -1;

The quibble is fine, but this last is a horror. We want a
constant, not a pre-initialized int. If you want c++, use the
appropriate newsgroup.

I think you've topped your own stupidity this time.

You are faulty. You have to learn the difference between a readonly
variable (const) and a const (letter, number).

When a variable classified as const were really a const and not only a
variable classified so then it wre legal to have a readonly variable
on the place a label requires a const.

const int i;

i: is illegal becaue i is not a const.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Ian Collins]

Ian Collins wrote:
Keith Thompson wrote:

[...]

#define MPSIZE 80
#define VALUE -1
int maxpat[MPSIZE], i;

for (i = 0; i < MPSIZE; i++) maxpat = VALUE;
[...]

Quibble:
#define VALUE (-1)

It doesn't matter in this case, but it's a good habit.
Better still

const int value = -1;

Yes, that's fine in this case, but only because it's not used in
a context that requires a constant expression. If it were, you'd
need to use either a macro or the enum trick:
enum { VALUE = -1 };
which works only for values of type int.

The quibble is fine, but this last is a horror. We want a
constant, not a pre-initialized int. If you want c++, use the
appropriate newsgroup.

It's perfect valid C. (The fact that it's also valid C++, and that
C++'s "const" is more flexible that C's, hardly seems relevant.)

So what? Among other things, it can tend to generate poor code.

Not on any compiler I've used recently. It generates the exact same
code as a literal constant.

The real constant (from the #define) can be loaded as an immediate
value. The improper const requires loading an address and then
loading a value from that address.
Nope.

And, once you have the constant
defined, it is usable elsewhere and is guaranteed to match values.

It also pollutes any scope where the #define is visible.

All I am saying is that the use of const here is a horrible
misuse.

It isn't, it's perfectly valid. It's the only way if you want to manage
the scope of the constant.

However the enum is a valid means of generating that
constant.

For integer types.

 

[Default User]

Your article was encoded as "quoted-printable", which means that '='
characters are encoded as "=3D". If you can persuade your newsreaqder
to post plain text rather than quoted-printable, it would be helpful.
Possibly my own newsreader should have done the translation when
saving the file, but there's nothing in what you posted that really
requires anything more elaborate than a plain-text encoding.

He posts from Google Groups, and that's one of the "features" of that
system. I started displaying the User-Agent header line so that I could
tell when a message was from GG (it will be set to G2/1.0).

It's possible you did indent your code, and your newsreader or
something else killed it. If so, please try to solve that problem.
If you're using tabs for indentation, try using just spaces. And make
sure you're using an editor that's designed to work with source code.

GG might eat tabs, or he might have neglected to indent. Spaces work
ok.




Brian

 

[Richard]

Ian Collins wrote:
Keith Thompson wrote:

[...]

#define MPSIZE 80
#define VALUE -1
int maxpat[MPSIZE], i;

for (i = 0; i < MPSIZE; i++) maxpat = VALUE;
[...]

Quibble:
#define VALUE (-1)

It doesn't matter in this case, but it's a good habit.

Better still

const int value = -1;

Yes, that's fine in this case, but only because it's not used in
a context that requires a constant expression. If it were, you'd
need to use either a macro or the enum trick:
enum { VALUE = -1 };
which works only for values of type int.

The quibble is fine, but this last is a horror. We want a
constant, not a pre-initialized int. If you want c++, use the
appropriate newsgroup.

It's perfect valid C. (The fact that it's also valid C++, and that
C++'s "const" is more flexible that C's, hardly seems relevant.)

So what? Among other things, it can tend to generate poor code.

Your views (incorrect at that) on compiler specifics are clearly off
topic. I am sure you would be the first to point that out to others who
were to post such rubbish.

 

[santosh]

Ian Collins wrote:
Keith Thompson wrote:

[...]

#define MPSIZE 80
#define VALUE -1
int maxpat[MPSIZE], i;

for (i = 0; i < MPSIZE; i++) maxpat = VALUE;
[...]

Quibble:
#define VALUE (-1)

It doesn't matter in this case, but it's a good habit.

Better still

const int value = -1;

Yes, that's fine in this case, but only because it's not used in
a context that requires a constant expression. If it were, you'd
need to use either a macro or the enum trick:
enum { VALUE = -1 };
which works only for values of type int.

The quibble is fine, but this last is a horror. We want a
constant, not a pre-initialized int. If you want c++, use the
appropriate newsgroup.

It's perfect valid C. (The fact that it's also valid C++, and that
C++'s "const" is more flexible that C's, hardly seems relevant.)

So what? Among other things, it can tend to generate poor code.

Your views (incorrect at that) on compiler specifics are clearly off
topic.

What compiler specifics?

<snip>

 

[Richard]

Keith Thompson wrote:
Ian Collins wrote:
Keith Thompson wrote:

[...]

#define MPSIZE 80
#define VALUE -1
int maxpat[MPSIZE], i;

for (i = 0; i < MPSIZE; i++) maxpat = VALUE;
[...]

Quibble:
#define VALUE (-1)

It doesn't matter in this case, but it's a good habit.

Better still

const int value = -1;

Yes, that's fine in this case, but only because it's not used in
a context that requires a constant expression. If it were, you'd
need to use either a macro or the enum trick:
enum { VALUE = -1 };
which works only for values of type int.

The quibble is fine, but this last is a horror. We want a
constant, not a pre-initialized int. If you want c++, use the
appropriate newsgroup.

It's perfect valid C. (The fact that it's also valid C++, and that
C++'s "const" is more flexible that C's, hardly seems relevant.)

So what? Among other things, it can tend to generate poor code.

Your views (incorrect at that) on compiler specifics are clearly off
topic.

What compiler specifics?

Please read the post I replied to. Hint : Falconer would not tolerate
the word "can" since code generation is alien to the standard.

For some reason known only to yourself you then continued to snip all
the "possibles" Falconer posted which are clearly guesswork and liable
to be compiler specific.

 

[Peter Nilsson]

For integer types.

....in the range of int.

 

[Chris Dollin]

Hi,

the following is actually a part of the pattern matching program which
i tried ,memset is not setting the entire integer array with
-1

int maxpat[80];
memset(maxpat,-1,80);

As the others have pointed out, it sets each byte to the value. There's
almost no way to do what you want with memset(), unless you happen to
be on a machine that had one-byte ints.

To set each int in the array to -1, you need a loop. Better yet,
explain WHY you want to do this. There may be a better construct.

I would be interested to hear how you knowing WHY he needs to set a
sequence of ints to a single value would in any way "optimise" your
advice.

Because it sometimes turns out that the /actual/ problem can be
solved in a different, perhaps better, way. Have you not met
problems that can be easily solved one higher level of
abstraction than their symptoms?

 

[Keith Thompson]

Ian Collins wrote:
Keith Thompson wrote:

[...]

#define MPSIZE 80
#define VALUE -1
int maxpat[MPSIZE], i;

for (i = 0; i < MPSIZE; i++) maxpat = VALUE;
[...]

Quibble:
#define VALUE (-1)

It doesn't matter in this case, but it's a good habit.
Better still

const int value = -1;

The quibble is fine, but this last is a horror. We want a
constant, not a pre-initialized int. If you want c++, use the
appropriate newsgroup.

I think you've topped your own stupidity this time.

You are faulty. You have to learn the difference between a readonly
variable (const) and a const (letter, number).

You mean between a readonly variable (const) and a *constant*.
(Though I prefer to refer to the former as a read-only *object*, just
to avoid the confusion of a "variable" that isn't allowed to vary.)

But the point is that in the above code a const-qualified object will
work; the context is not one that requires a constant expression.

Even though the word "const" is derived from "constant", IMHO it's
best to pretend that "const" is *not* an abbreviation for "constant",
and particularly to avoid using the two words interchangeably.

When a variable classified as const were really a const and not only a
variable classified so then it wre legal to have a readonly variable
on the place a label requires a const.

const int i;

i: is illegal becaue i is not a const.

Um, do you think you could rephrase that?

Oddly enough, the declaration
const int i;
is legal, though not at all useful (at least at block scope).

 

[Keith Thompson]

CBFalconer wrote: [...]

However the enum is a valid means of generating that
constant.

For integer types.

Only for type int, actually. This:

enum { too_big = INT_MAX + 1 };

is invalid (though I'm not sure which kind of invalid it is).

 

[Ian Collins]

You are faulty. You have to learn the difference between a readonly
variable (const) and a const (letter, number).

Nonsense. Use of const int was correct in this situation.

When a variable classified as const were really a const and not only a
variable classified so then it wre legal to have a readonly variable
on the place a label requires a const.

I don't really understand that sentence, care to try again?

const int i;

i: is illegal becaue i is not a const.

It's legal by C's daft const rules, but useless.

 

[Ian Collins]

CBFalconer wrote: [...]

However the enum is a valid means of generating that
constant.

For integer types.

Only for type int, actually. This:

enum { too_big = INT_MAX + 1 };

is invalid (though I'm not sure which kind of invalid it is).

Probably the invalid type...

Which all goes to strengthen my case that an initialised, const
qualified variable is the best choice for anything other than a compile
time constant.

 

[Harald van Dijk]

This:

enum { too_big = INT_MAX + 1 };

is invalid (though I'm not sure which kind of invalid it is).

It's a constraint violation, according to the interpretation at
<http://open-std.org/JTC1/SC22/WG14/www/docs/dr_031.html>

 

[Serve Laurijssen]

What is the representation of -1 in a sign magnitude system with a
32-bit int and an 8 bit char? How much of that representation will
memset use? What will be the resulting bit pattern in one of the
elements of maxpat? What value will this represent? Will this
achieve the intended objective as posed in the original post? How is
this value different from a 2s-complement machine? From a
1s-complement machine?

yes yes I dont think you all understand me, but never mind

 

[Ian Collins]

Because a const qualified object is simply marked as read-only.
There are various ways of getting around this and arranging to
change what that object is holding. At which point any code that
treats its value as being a constant is WRONG.

No, the code that's "getting around this" is wrong. Once you mess about
with the value of a const qualified variable, you unleash the demons of
Undefined Behaviour.

 

[Keith Thompson]

Because a const qualified object is simply marked as read-only.
There are various ways of getting around this and arranging to
change what that object is holding. At which point any code that
treats its value as being a constant is WRONG.

Ok, consider this:

#include <stdio.h>
int main(void)
{
const int x = 42;

/* ... */

printf("x = %d\n", x);
return 0;
}

Can you think of something you could insert in place of the comment
that would change the value of x *without invoking undefined
behavior*? (Hint: No.)

Both the compiler and the programmer are entitled to assume that the
value of x is 42 at the point of the printf call. The compiler could
legally replace the call with puts("x = 42"). If you insert code to
change the value of x, then you've invoked undefined behavior, and
printing "x = 42" is merely one possible consequence.

The compiler is not required to replace references to x with the
constant 42, but it's certainly allowed to do so. (Note that this
might not even be an optimization; depending on the CPU, you might get
faster code by loading the value of x, particularly if it happens to
be stored in a register, than by loading a literal value.)