Skip to content

Commit

Permalink
@tzcoolman, looks like the fastq parser does not account for single \…
Browse files Browse the repository at this point in the history 
…n lines #reviewthis please
  • Loading branch information
Roman Valls Guimera committed Jun 29, 2014
1 parent 2ff56a5 commit a79ec85
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 1 deletion.
1 change: 1 addition & 0 deletions facs/query.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -396,6 +396,7 @@ void read_process (bloom * bl, Queue * info, Queue * tail, F_set * File_head, fl
int result = 0;
next_job = check_fmt (info, tail, start_point, fmt_type);
// make sure it can handle DOS and Unix format ('\r\n' and '\n')
// XXX: what about OSX sinle '\n' ('a0' in hexa)?
if (next_job == NULL)
return;
while (start_point != next_job)
Expand Down
2 changes: 1 addition & 1 deletion facs/tool.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -340,7 +340,7 @@ char *check_fmt (Queue *info, Queue *tail, char *start_point, char type)
next_job = info->next->location;
}
else
{
{ // XXX: Does this account for OSX-style newlines? next_job is always NULL on OSX fastq files.
next_job = strchr (start_point, '\0');
if (next_job[-1] == '\n' && next_job[-2] == '\n')
next_job -= 1;
Expand Down

3 comments on commit a79ec85

@tzcoolman
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brainstorm Line 345 expects an UNIX or DOS style new lines. I thought OSX fastq files share exactly the same format as UNIX fastq files. Can you give me an example of how OSX fastq files looks like? (especially the '\n' and '\0' in OSX?)

@tzcoolman
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brainstorm when you say NULL? you mean the 'next_job' you print after line 344? next_job is either the position of next job to be handled or the end of all jobs. I think NULL is correct since strchr (start_point, '\0') is looking for a 'NULL' char, which is '\0'. Does it give the incorrect result when it is used on OSX?

@brainstorm
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, disregard this issue, I was hunting for the real bug and it seems to be the behaviour of the python C-extension in OSX (works in Linux). I'm trying to fix it by migrating to SWIG instead.

Please sign in to comment.