I want to use atoi function in my program, but I found it not working.
#include <ctype.h>
int value;
value=atoi(buf);
char buf points to "1000" or something like, terminated by \0. I have checked it.
But the value evaluates always to zero. I have tried strtol(), but I get the same error.
My ADS (ARM Developer Suit) is v1.2 (s3c2440). I can find the libs in armlib path (c_t_xx.l).
I use axd debug mode, so I can trace my code. I found "bl
__rt_ctype_table", so I think asm code linked right.
Please give any advice to fix this issue.
ARM might have a problem with string functions, you haven't mentioned whether it returns a value and it's incorrect (i heard it's a bug and it's better you should write the function on your own) or there is no value at all.
anyway look at the arm article about it i think it's the solution - ARM article about string functions
The following code should work,
#include <stdio.h>
#include <stdlib.h>
int main()
{
int i;
char buff[5] = "1000\0";
i=atoi(buff);
printf("i=%d\n", i);
return 0;
}
#./a.out
#i=1000
Related
I have made a library that handle strings in c.
I've added it in another project CMakeLists. Issue is that, whenever i want to call a function from that library, it crash.
However, if i call the same function from the library itself, no crash, the function call is handled properly.
I kept thinking that i did something wrong with my CMakeLists but as far as i'm aware and the different methods i used to arrive to the same conclusion, it doesn't look like it anymore.
I tried running the test in question in gdb and this is what it returned
Starting program: C:\Users\s\Documents\Repo\C\Projet\lib\rule\build\test-create-destroy.exe
gdb: unknown target exception 0xc0000135 at 0x7ffdfa70cf40
gdb: unknown target exception 0xc0000135 at 0x7ffdfa70cf40
Program received signal ?, Unknown signal.
0x00007ffdfa70cf40 in ntdll!RtlRaiseStatus () from C:\Windows\SYSTEM32\ntdll.dll
I've read that it could be an issue related to memory allocation errors, but if this was the case, why would i be able to call the function without any error directly from my library?
replit of fairly simple example: https://replit.com/#Mrcubix-Mrcubix/EmbellishedOldfashionedBaitware#lib/rule/src/test-create-destroy.c
Here is the function called in the library in question, to keep it simple:
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
typedef struct _String
{
unsigned int size;
char *string;
} String;
String *create_string(char *chr)
{
String *str = malloc(sizeof(String));
str->size = strlen(chr);
str->string = malloc(str->size + 1);
memcpy(str->string, chr, str->size);
str->string[str->size] = '\0';
return str;
}
void destroy_string(String *str)
{
free(str);
}
Here the second library i'm calling a function from which work as it's part of the same project:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <string-struct.h>
typedef struct _rule
{
String *premise;
String *conclusion;
} rule;
rule *create_rule(String *premise, String *conclusion)
{
rule *r = calloc(1, 16);
r->premise = premise;
r->conclusion = conclusion;
return r;
}
void destroy_rule(rule *r)
{
free(r);
}
here is the CMakeLists used by Rulestruct:
cmake_minimum_required(VERSION 3.0)
project("Rulestruct")
find_package(Stringstruct)
include_directories(${STRINGSTRUCT_INCLUDE_DIRS})
link_directories(${STRINGSTRUCT_LIB_DIRS})
add_library(rulestruct SHARED "${CMAKE_CURRENT_SOURCE_DIR}/src/rule-struct.c" "${CMAKE_CURRENT_SOURCE_DIR}/src/rule-struct.h")
target_link_libraries(rulestruct ${STRINGSTRUCT_LIBRARIES})
add_executable(test-create-destroy "${CMAKE_CURRENT_SOURCE_DIR}/src/test-create-destroy.c" "${CMAKE_CURRENT_SOURCE_DIR}/src/rule-struct.h")
add_dependencies(test-create-destroy rulestruct)
target_link_libraries(test-create-destroy rulestruct)
and finally, here is where i call the function from (test-create-destroy.c)
#include <assert.h>
#include <string-struct.h>
#include "rule-struct.h"
#include "rules-struct.inc"
int main(void)
{
String *premise = create_string("1 2"); // location of crash
String *conclusion = create_string("3"); // location of crash
/*rule *rule_A = create_rule(premise, conclusion);
assert(string_char_equal(rule_A->premise, "1 2"));
assert(!string_char_equal(rule_A->premise, "3"));
assert(string_char_equal(rule_A->conclusion, "3"));
assert(!string_char_equal(rule_A->conclusion, "1 2"));
destroy_rule(rule_A);*/
destroy_string(premise);
destroy_string(conclusion);
}
Here are screenshots of bin, lib and cmake-gui: https://imgur.com/a/3OdrC2D
I could probably fix it on every project provided i know what i did wrong and why,
So if anyone could provide further explanation then i'll glad to read it.
I will also take tips about issues or potential issues related to my CMakeLists as i have a hard time understanding any of it, needing to mix multiple examples and the documentation to have a very small bit of understanding of why something is done this or that way.
TLDR: Function called elsewhere than inside the library = crash, accept tips about other parts of the presented data (CMakeLists).
Gladly accept further explanation of the core of the issue.
I'm running OS X Sierra and trying to compile a c program that uses strcpy_s, but my installed clang compiler is using the c99 standard, but from what I've read strcpy_s requires c11.
Here's the code I'm trying to compile
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void)
{
char source[] = "Test string";
char destination[50];
if(strcpy_s(destination, sizeof(destination), source))
printf("string copied - %s",destination);
return 0;
}
And here's the command I'm using to compile
$ clang copytest.c -o copytest
copytest.c:11:5: warning: implicit declaration of function 'strcpy_s' is invalid in C99 [-Wimplicit-function-declaration]
if(strcpy_s(copied_string, sizeof(copied_string), source))
^
1 warning generated.
Undefined symbols for architecture x86_64:
"_strcpy_s", referenced from:
_main in copytest-e1e05a.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've tried compiling with the standard flag...
clang -std=c11 copytest.c -o copytest
but I get the same exact "invalid in c99" warning. I've also tried compiling with gcc instead, and I still get the same c99 warning.
I tried upgrading via homebrew which shows the following
Warning: gcc 9.2.0 is already installed and up-to-date
I have clang version 9.0.0
$ clang -v
Apple LLVM version 9.0.0 (clang-900.0.39.2)
My xcode version is Xcode 9.2, which from everything I've read should come with c11 support.
Am I doing something wrong with the compiling, is my code itself incorrect? This is the only similar question I found on here, but it didn't even have an answer. Thanks
The _s functions are an optional component of the 2011 C standard (Annex K), and, to the best of my knowledge, they have never been implemented as an integrated part of any C library. Portable code cannot rely on their availability. (Microsoft's C compilers for Windows implement an overlapping set of functions with the same names but different semantics (and sometimes even a different argument list), and at least one bolt-on implementation does exist. See this old answer, and the much longer question and answer it links to, for more detail.)
Also, the _s functions do not solve the problem that they were intended to solve (unsafe string handling); it is necessary to put actual thought into a proper fix for each use of strcpy, instead of globally search-and-replacing strcpy with strcpy_s, etc., as was the hope of the authors of Annex K. If you do put appropriate amounts of thought into a proper fix, you won't need any of the _s functions to implement it. For instance, here's a fixed version of your example program:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void)
{
char source[] = "Test string";
char destination[50];
size_t srclen = strlen(source);
if (srclen + 1 > sizeof destination) {
fprintf(stderr, "string too long to copy - %zu bytes, need %zu\n",
sizeof destination, srclen + 1);
return 1;
} else {
memcpy(destination, source, srclen + 1);
printf("string copied - %s\n", destination);
return 0;
}
}
And here's an even better version:
#define _XOPEN_SOURCE 700
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
if (argc != 2) {
fprintf(stderr, "usage: ./test 'message of arbitrary length'\n");
return 1;
}
char *destination = strdup(argv[1]);
if (!destination) {
perror("strdup");
return 1;
}
printf("string copied - '%s'\n", destination);
free(destination);
return 0;
}
Therefore: Never use any of the _s functions. If you need to write a program that compiles on Windows with no warnings, put #define _CRT_SECURE_NO_WARNINGS 1 at the top of each file to make MSVC stop giving you bad advice.
If all, or even most, programmers wrote the suggested solutions above all the time, then these functions wouldn't be needed. We have a lot of evidence that many programmers do not write such careful code, going back to Spaf's notes on the Robert T Morris finger worm in the late 1980's.
You also would prefer not to have to duplicate 10 lines of code for every call site of strcpy. That leads to unreadable code. More so, what zwol suggests is really just an implementation of the function he claims we don't need. A good programmer would take that, stick it in a header, and name it something helpful, maybe checked_strcpy? Or even strcpy_s?
The second suggested implementation, which is purportedly better is not - it would cause an allocation when we might already have a buffer. Allocations are expensive, using this approach everywhere would be bad for perf. It also introduces new complexity because now we'd have to free every duplicated string - imagine doing that with repeated calls to strcat.
There is a fairly nicely done cross-platform implementation here:
https://github.com/intel/safestringlib
I'm also not sure whether this is actually any different, but worth taking a look - https://github.com/coruus/safeclib
I am new to C programming and I am currently learning loops. In the below program,
#include<stdio.h>
main()
{
int i;
for(i=1;i++<=5;printf("%d",i));
}
i tried to compile in dev c++ compiler but it is giving error "[Error] ld returned 1 exit status"
You need to include the <stdio.h> header, and also, main needs a return type (int) and a return value. Changing the program to this will make it compile (at least it did using GCC) and run:
#include <stdio.h>
int main(int argc, char *argv[])
{
int i;
for(i=1;i++<=5;printf("%d",i));
return 0;
}
The quotes you used in the “%d” are illegal too, use normal quotes: "%d".
Apart from that, doing the printf inside the loop head might be legal, but it's pretty bad style. Usually in a for-loop you would have have initialization;condition;increment(or decrement or w/e) in the head, and do side-effects in the body of the statement.
I would try writing the for loop as:
for(i=1;i < 6;i++) { printf(“%d”,i); }
I have run this program manually on my notebook and i got Output 23456
Then i run this on Dev c++ and it is giving the same output 23456 without any error and i have just copied and pasted from ur question dun know why its showing error on ur runtime may be u have not saved it as C file
this is my first time posting to this forum so if I neglect any formalities or bother anyone in any way with something similar please let me know and I'll do my best to avoid doing it again!
I am trying to generate two arrays using the following code, but I am having a problem actually outputting the code. I know this is probably something very basic, but I just started using C only about two weeks ago. I'm quite sure everything is correct, but for some reason when I try to compile the code while linking the math library with gcc static.c -lm -o static and then when I further ask for the output using ./static, I am given no output and am asked for the next command. What am I doing wrong?
If this is something simple or an oversight then the odds are I am missing something conceptually and if you wouldn't mind elaborating on it I would really appreciate it. thank you!
#include <stdio.h>
#include <stdlib.h>
#define N 100
#define pi 3.14
#include <math.h>
int main (void) {
double x[N], f[N];
int i;
for (i = 0; i < N; i++) {
x[i] = (double)(i) / ((double)(N) - 1.0);
f[i] = sin(2.0 * pi * x[i]);
}
return EXIT_SUCCESS;
printf("x is %f",x[i]);
}
You already return success and the code below will not be executed. Swap the two statements.
printf("x is %f",x[i]);
return EXIT_SUCCESS;
Your printf is after the return, so your code doesn't actually reach it. You need to have it before.
I have seen a strange behavior with "strndup" call on AIX 5.3 and 6.1.
If I call strndup with size more than the size of actual source string length, then there is a stack corruption after that call.
Following is the sample code where this issue can come:
int main ()
{
char *dst_str = NULL;
char src_str[1023] = "sample string";
dst_str = strndup(src_str, sizeof(src_str));
free(dst_str);
return 0;
}
Does anybody have experienced this behavior?
If yes please let me know.
As per my observation, there must be a patch from OS where this issue got fixed. but i could not get that patch if at all there is any. Please throw some light.
Thanks & Regards,
Thumbeti
You are missing a #include <string.h> in your code. Please try that—I am fairly sure it will work. The reason is that without the #include <string.h>, there is no prototype for strndup() in scope, so the compiler assumes that strndup() returns an int, and takes an unspecified number of parameters. That is obviously wrong. (I am assuming you're compiling in POSIX compliant mode, so strndup() is available to you.)
For this reason, it is always useful to compile code with warnings enabled.
If your problem persists even after the change, there might be a bug.
Edit: Looks like there might be a problem with strndup() on AIX: the problem seems to be in a broken strnlen() function on AIX. If, even after #include <string.h> you see the problem, it is likely you're seeing the bug. A google search shows a long list of results about it.
Edit 2:
Can you please try the following program and post the results?
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
char *test1 = "abcdefghijabcdefghijabcdefghijk";
char *test2 = "012345678901234567890123456789";
char *control = "01234567890123456789012345678";
char *verify;
free(strndup(test1, 30));
verify = strndup(test2, 29); /* shorter then first strndup !!! */
fprintf(stderr,">%s<\n",verify);
if (strcmp(control, verify))
printf("strndup is broken\n");
}
(Taken from https://bugzilla.samba.org/show_bug.cgi?id=1097#c10.)
Edit 3: After seeing your output, which is >01234567890123456789012345678<, and with no strndup is broken, I don't think your version of AIX has the strndup bug.
Most likely you are corrupting memory somewhere (given the fact that the problem only appears in a large program, under certain conditions). Can you make a small, complete, compilable example that exhibits the stack corruption problem? Otherwise, you will have to debug your memory allocation/deallocation in your program. There are many programs to help you do that, such as valgrind, glibc mcheck, dmalloc, electricfence, etc.
Old topic, but I have experienced this issue as well. A simple test program on AIX 6.1, in conjunction with AIX's MALLOCDEBUG confirms the issue.
#include <string.h>
int main(void)
{
char test[32] = "1234";
char *newbuf = NULL;
newbuf = strndup(test, sizeof(test)-1);
}
Compile and run the program with buffer overflow detection:
~$ gcc -g test_strndup2.c
~$ MALLOCDEBUG=catch_overflow ./a.out
Segmentation fault (core dumped)
Now run dbx to analyze the core:
~$ dbx ./a.out /var/Corefiles/core.6225952.22190412
Type 'help' for help.
[using memory image in /var/Corefiles/core.6225952.22190412]
reading symbolic information ...
Segmentation fault in strncpy at 0xd0139efc
0xd0139efc (strncpy+0xdc) 9cc50001 stbu r6,0x1(r5)
(dbx) where
strncpy() at 0xd0139efc
strndup#AF5_3(??, ??) at 0xd03f3f34
main(), line 8 in "test_strndup2.c"
Tracing through the instructions in strndup, it appears that it mallocs a buffer that is just large enough to handle the string in s plus a NULL terminator. However, it will always copy n characters to the new buffer, padding with zeros if necessary, causing a buffer overflow if strlen(s) < n.
char* strndup(const char*s, size_t n)
{
char* newbuf = (char*)malloc(strnlen(s, n) + 1);
strncpy(newbuf, s, n-1);
return newbuf;
}
Alok is right. and with the gcc toolchain under glibc, you would need to define _GNU_SOURCE to get the decl of strndup, otherwise it's not decl'd, e.g.:
#include <string.h>
...
compilo:
gcc -D_GNU_SOURCE a.c
Thanks a lot for your prompt responses.
I have tried the given program.
following is the result:
bash-2.05b# ./mystrndup3
>01234567890123456789012345678<
In my program I have included , still problem is persistent.
Following is the strndup declaration in prepossessed code.
extern char * strndup(const char *, size_t);
I would like to clarify one thing, with small program I don't get effect of stack corruption. It is consistently appearing in my product which has huge amount of function calls.
Using strndup in the following way solved the problem:
dst_str = strndup(src_str, srtlen(src_str));
Please note: used strlen instead of sizeof as i need only the valid string.
I am trying to understand why it is happening.
Behavior i am seeing with my product when i use strndup with large size:
At the "exit" of main, execution is coring with "illegal instruction"
intermittently "Illegal Instruction" in the middle of execution (after strndup call).
Corrupt of some allocated memory, which is no where related to strndup.
All these issues are resolved by just modifying the usage of strndup with actual size of source string.
Thanks & Regards,
Thumbeti