pointer from integer without a cast

[Ben Bacarisse]

Or what if the file name is something like "rm -rf $HOME", which could
cause system(myCommand) to succeed with disastrous results?

Not given the code that was shown, but in general, yes.

 

[88888 Dihedral]

Dear friends,

I am a C novice. I am trying to get the basename of a file(filename) without extension. The problem is much discussed in net, but due to my limited knowledge, I failed to make fruitful use of them, and thought I may use the unix command, as given.
char myCommand[512];

// char *basetmp=strrchr(filename,'/')+1;

sprintf(myCommand,"basename %s .bib",filename);

char *basefn=system((char *)myCommand);

printf (basefn);

variable filename is defined as char*.

This code is giving warnning:308:18: warning: initialization makes pointer from integer without a cast [enabled by default]

where line no 308 is "char *basefn=system((char *)myCommand);"

If anybody kindly show me where I am getting wrong, or better still, a better(and small) method to get the same function without unix command, it will be of huge help.

The C function system() does not return the "output" of the command it

executes. It returns an implementation-defined "status" which has

type int. (Most commands return 0 status to indicate success.)



In this case, the output from basename probably went directly to your

screen. One way for you to get the output, if your system supports

redirection (>>), would be to add " >> basename_output_file.txt" to

your sprintf format string and then open the file and read the output.



By the way, your cast in the call to system() serves no purpose.

myCommand is an array of char. In this context, the expression

myCommand is automatically converted to &myCommand[0] which already

has type char*.

Uhn, how to efficiently exchange one or more objects of different processes
for different processes to process the exchanged objects is the OS level
problem.

Well, how to support some clipborad approach in an OS by adding some
programming features in the programming language is the language issue.

 

[Ben Bacarisse]

On 8/29/2012 4:30 PM, Ben Bacarisse wrote:

Is that the contents, or the name, of the file? I'm pretty sure that
*nix doesn't allow "/" to be part of a filename.

Good catch. Yes, 'twas the name. I wanted something to act as file
name before the rm because the code in question appends the name to a
command (and that what most such bad examples do):

sprintf(cbuf, "basename %s .bib", filename);

I should have picked, say, ".; rm -rf ~; echo'. The reason for the
"echo" was just to lessen the chances of errors foiling the execution.
In the case cited, the command would have become:

basename .; rm -rf ~; echo .bib

which is nicely well-formed.

On the other hand, a filename of "-rf .." is always "fun" to get a
newbie to remove. Or perhaps "foo ; cd .. ; cd .. ; cd .. ; rm -rf
*".

Yes, the latter works. You need a ; (or || or some such syntax) to
start a new command.

 

[Fred K]

On 8/30/2012 9:32 PM, Ben Bacarisse wrote: > Kenneth Brody <[email protected]> writes: > >> On 8/29/2012 4:30 PM, Ben Bacarisse wrote: > <snip> >>> or at least a remark that '/; rm -rf ~; echo' is my favourite test file.>> >> Is that the contents, or the name, of the file? I'm pretty sure that>> *nix doesn't allow "/" to be part of a filename. > > Good catch. Yes, 'twas the name. I wanted something to act as file > name before the rm because the code in question appends the name to a > command (and that what mostsuch bad examples do): [...] On *nix, the only characters not allow in a filename are '/' and '\0'. (Obviously, '/' can be part of a full pathname.) This has led to some "interesting" filenames I've seen over the years. Numerous times, I've run across "inaccessible" files. For example, "ls -l" would show a filename of "foobar", yet any attempt to access "foobar" resulted in a "file not found" error. Using "ls -l | cat -v", on the other hand, would show a name like "fooo^[[Dbar", which was apparently created by someone using the left-arrow rather than the backspace key to correct the typo. -- Kenneth Brody

I've also seen a backspace in the name of a file. Not easy to create.

 

[Jorgen Grahn]

On 8/30/2012 9:32 PM, Ben Bacarisse wrote: > Kenneth Brody [...]

Ugh, fix your newsreader. You managed to mangle those quotes into a
single 1000-character line.

I've also seen a backspace in the name of a file. Not easy to create.

% perl -e 'open FOO, ">hard\b\b\b\beasy" or die'
% echo hard*
easy

The C solution is left as an exercise.

/Jorgen

 

[Seungbeom Kim]

To provide a context for the following paragraphs:

int array[10];
int *end_of_array = array+9;
int *P;
int a, b;

The C standard says "if the expression P points to the last
element of an array object, the expression (P)+1 points one past the
last element of the array object," (6.5.6p8). This statement only
applies to additions of 1, and only to pointers that point "to the last
element of an array object. It doesn't apply to adding any number other
than 1, nor does it apply to adding an integer to a pointer that points
at any location other than the last element of an array object.
[...]

I consider this a defect in the standard, not a statement of how C
actually works, nor of how it should work. I think the definition of the
way a pointer one past the end of an array can be created should be
expanded to cover (array+8)+2 and (array+7)+3, and not just (array+9)+1.
People who are in a position to get the wording corrected don't agree
with me.

6.5.6p8 also says:

: If both the pointer operand and the result point to elements of the
: same array object, or one past the last element of the array object,
: the evaluation shall not produce an overflow; otherwise, the behavior
: is undefined.

Doesn't this already define a well-defined result for (array+8)+2, etc.?

 

[James Kuyper]

To provide a context for the following paragraphs:

int array[10];
int *end_of_array = array+9;
int *P;
int a, b;

The C standard says "if the expression P points to the last
element of an array object, the expression (P)+1 points one past the
last element of the array object," (6.5.6p8). This statement only
applies to additions of 1, and only to pointers that point "to the last
element of an array object. It doesn't apply to adding any number other
than 1, nor does it apply to adding an integer to a pointer that points
at any location other than the last element of an array object.

....
6.5.6p8 also says:

: If both the pointer operand and the result point to elements of the
: same array object, or one past the last element of the array object,
: the evaluation shall not produce an overflow; otherwise, the behavior
: is undefined.

Doesn't this already define a well-defined result for (array+8)+2, etc.?

OK - I'll bite: what is the well-defined result that it defines. and how
do you derive that conclusion from the cited words?

 

[lawrence.jones]

I consider this a defect in the standard, not a statement of how C
actually works, nor of how it should work. I think the definition of the
way a pointer one past the end of an array can be created should be
expanded to cover (array+8)+2 and (array+7)+3, and not just (array+9)+1.
People who are in a position to get the wording corrected don't agree
with me.

I wouldn't go quite that far, I think it's more accurate to say that they
don't consider it a serious enough defect to warrant spending any
significant amount of time on, given that there isn't an obvious
rewording to correct it. If you'd like to propose words, I'd be glad to
consider them.

I'm reasonably sure there's at least one DR response where the committee
affirms that "how it should work" is what they intended.

 

[James Kuyper]

I wouldn't go quite that far, I think it's more accurate to say that they
don't consider it a serious enough defect to warrant spending any
significant amount of time on, given that there isn't an obvious
rewording to correct it. If you'd like to propose words, I'd be glad to
consider them.

Current wording:

" ... if the expression P points to the last element of an array object,
the expression (P)+1 points one past the last element of the
array object, and if the expression Q points one past the last element
of an array object, the expression (Q)-1 points to the last element of
the array object. ..."

Change to:

" ... if the expression P points to the m-th element of an array object
containing n elements, the expression (P)+(1+n-m) points one past the
last element of the array object, and if the expression Q points one
past the last element of an array object containing n elements, then the
expression (Q) - (1+n-m) points at the m-th element of the array object,
provided it exists. ..."

I proposed essentially the same wording to you in a message posted to
comp.std.c on 2010-10-01 21:59 -0400, with the Subject "Re: C standard
does not fully define array + sizeof_array". There was no response to
my proposal message, not from you, nor from anyone else, at least none
that was archived by Google Groups.

I'm reasonably sure there's at least one DR response where the committee
affirms that "how it should work" is what they intended.

I wouldn't be surprised - but the wording should still be changed to
match the intent.

 

[lawrence.jones]

I proposed essentially the same wording to you in a message posted to
comp.std.c on 2010-10-01 21:59 -0400, with the Subject "Re: C standard
does not fully define array + sizeof_array". There was no response to
my proposal message, not from you, nor from anyone else, at least none
that was archived by Google Groups.

I must not have seen it, then. I've made a note; thanks!

 

[Kaz Kylheku]

I must not have seen it, then. I've made a note; thanks!

Yes, and moreover, for integer overflow, they should specify all the
possibilities.

There may be some fifth grade dropout reading that text who might not be able
to deduce that INT_MAX+1 being undefined also implies that (INT_MAX-1)+2 is
undefined.

A document that can't be grokked by fifth grade dropouts is intellectually
elitist.