strtok

C - Unexpected Segmentation Fault on strtok(…)

╄→尐↘猪︶ㄣ 提交于 2019-12-01 00:42:24
I am using strtok(...) of the library and it appears to be working fine until the end condition, where it results in a segmentation fault and program crash. The API claims that strtok(...) will output a NULL when there are no more tokens to be found, which meant, I thought, that you had to catch this NULL in order to terminate any loops that you were running using strtok(...). What do I need to do to catch this NULL to prevent my program from crashing? I imagined the NULL was allowed for use as a terminating condition. I have prepared a SSCCE for you to observe this behavior. I need strtok(...

why do we use NULL in strtok()?

纵然是瞬间 提交于 2019-11-30 10:32:51
Why do we use null in strok() function? while(h!=NULL) { h=strtok(NULL,delim); if(hold!=NULL) printf("%s",hold); } What does this program do when *h is pointing to a string? strtok is part of the C library and what it does is splitting a C null-delimited string into tokens separated by any delimiter you specify. The first call to strtok must pass the C string to tokenize, and subsequent calls must specify NULL as the first argument, which tells the function to continue tokenizing the string you passed in first. The return value of the function returns a C string that is the current token

Parse $PATH variable and save the directory names into an array of strings

安稳与你 提交于 2019-11-30 09:28:10
问题 I want to parse the $PATH variable of Linux, and then save the directory names that are getting separated with ':' into an array of strings. I know it's a simple task but I am stuck and any help would be nice. My code so far is something like this but something ain't right. char **array; char *path_string; char *path_var = getenv("PATH"); int size_of_path_var = strlen(path_var); path_string = strtok(path_var, ":"); while (path_string != NULL) { ss = strlen(path_string) array[i] = (char *

Why should strtok() be deprecated?

随声附和 提交于 2019-11-30 01:28:47
问题 I hear this from a lot of programmers that the use of strtok maybe deprecated in near future. Some say it is still. Why is it a bad choice? strtok() works great in tokenizing a given string. Does it have to do anything with the time and space complexities? Best link I found on the internet was this. But that doesn't seem to solve my curiousity. Suggest any alternatives if possible. 回答1: Why is it a bad choice? The fundamental technique for solving problems by programming is to construct

Parse $PATH variable and save the directory names into an array of strings

隐身守侯 提交于 2019-11-29 15:22:05
I want to parse the $PATH variable of Linux, and then save the directory names that are getting separated with ':' into an array of strings. I know it's a simple task but I am stuck and any help would be nice. My code so far is something like this but something ain't right. char **array; char *path_string; char *path_var = getenv("PATH"); int size_of_path_var = strlen(path_var); path_string = strtok(path_var, ":"); while (path_string != NULL) { ss = strlen(path_string) array[i] = (char *)malloc(ss + 1); array[i] = path_string; //this is actually all i want to do for every path i++; path_string

Problem with strtok and segmentation fault

巧了我就是萌 提交于 2019-11-29 14:03:13
I have two helper functions to break up strings in the format of decimal prices ie. "23.00", "2.30" Consider this: char price[4] = "2.20"; unsigned getDollars(char *price) { return atoi(strtok(price, ".")); } unsigned getCents(char *price) { strtok(price, "."); return atoi(strtok(NULL, ".")); } Now when I run the below I get a segmentation fault: printf("%u\n", getDollars(string)); printf("%u\n", getCents(string)); However when I run them seperately without one following the other, they work fine. What am I missing here? Do I have to do some sort of resetting of strtok?? My solution: With the

linux下strtok和strtok_r的使用

左心房为你撑大大i 提交于 2019-11-29 13:38:17
头文件 <string.h> 一、strtok .原型 char * strtok(char * s,const char * delim); 功能 对字符串进行分段处理,每次调用strtok,返回由delim中任意一个字符分隔的一段字符串。 参数说明:@s:输入字符串,且该字符串不能为const类型。 @delim:所有用于将@s进行分隔的字符 @return:每调用一次,返回字符串中的一段,以'\0'结束 使用注意:第一次调用,传s进去,后面的调用都传NULL。 函数实现原理:将@s中的所有delim字符都替换为‘\0',即原来字符串自动被分为多段,当传入的@s为NULL时,自动调用下一段;@s不为NULL时,返回从@s开始的第一段 eg. char s[] = "111:222"; char *p = strtok (s, ":"); printf ("%s\r\n", p); //打印出111 printf ("%s\r\n", s); //同样打印出111,因为原来@s中的":"被替换为'\0',截断了字符串。 p = strtok (NULL, ":"); //注意传入参数为NULL。 printf ("%s\r\n", p); //打印出222,原@s的第二段字符串 二、strtok_r 原型 char *strtok_r(char *s, const char

strtok_r使用

北慕城南 提交于 2019-11-29 13:38:01
strtok函数 原型: char * strtok(char *s, const char *delim); 描述:分解字符串为一组字符串。s为要分解的字符串,delim为分隔符字符串。 当strtok()在参数s 的字符串中发现到参数delim 的分割字符时则会将该字符改为\0 字符。在第一次调用时,strtok()必需给予参数s 字符串,往后的调用则将参数s 设置成NULL。每次调用成功则返回下一个分割后的字符串指针。 输入:char *s -要分解的字符串,strtok在调用的时候会忽略起始位置开始的分隔符 。 const char *delim -分隔符字符串 输出:char* -提取到子串时,返回值是提取到的子串的指针,该指针指向的是子串在源字符串中的起始位置, 子串末尾的下一个字符提取前是分隔符,提取后被修改成了'\0'。 没有提取到子串,即源字符串中没有分隔符字符串的分隔符,返回的是源字符串的首地址。 分解子串时,如果分解已指向源字符串的尾部时,无法再继续分解,此时返回NULL。 strtok实现使用了静态变量,所以该函数是不可重入的,线程安全的函数是strtok_r。 strtok_r函数 原型: char *strtok_r(char *s, const char *delim, char **saveptr); 描述:strtok函数的可重入版本,char *

strtok 和strtok_r 函数使用

只愿长相守 提交于 2019-11-29 13:37:31
strtok这个函数我们再熟悉不过了,因为我们要经常要和字符打交道,不可避免的要分割字符串连接字符串。那么我今天看一下分割字符串。 strtok 函数原型char* strtok(char *str,const char *delimiters); 来分析一下这个分割字符串函数,这个函数是在传入的字符数组里进行调整,它并没有生成新的字符数组。 第一个参数可以是字符数组或者NULL,第一次切割传要切割的字符,第二次要在原来字符数组上继续切割就传NULL; 第二个参数传入的是切割符,这个参数看起来简单其实是比第一个还复杂,它传入的是一个字符串,而不是一个字符。 我们知道切割符是一个字符这个很好理解,但是传入一个字符串那函数是怎么进行切割的呢? my_strtok函数的实现 #include <stdio.h> #include <string.h> char *my_strtok(char *buff, char* delimit) { static char *p = NULL; //定义一个静态的字符指针 p if(buff == NULL && (buff = p) == NULL) //这个if语句特别重要,解决第一个参数传入的问题 { //第一个参数是buff不为NULL,if第一条buff == NULL就为非 return NULL; //不执行后面的赋值语句和判断语句,

字符串分割strtok_s

心已入冬 提交于 2019-11-29 13:37:14
strtok_s() 参数1:需要分割的字符串 参数2:字符串界限符 delimit 参数3:字符串位置 char szSrc[256]{0}; char *PNext=nullptr; char *pResult; pResult=strtok_s(szBuffer, "|", &PNext); while (nullptr!=str) { pResult=strtok_s(NULL, "|", &PNext); } 来源: CSDN 作者: covogol 链接: https://blog.csdn.net/u012023801/article/details/40016237