注释
.jpg "nuts_bolts.c 中的 strtod() 可能会读取比您预期更多的行 #122"){kind=avatar}
|
这是针对您的nuts_bolts.c (HEAD) 的修复，以使其尽可能容易地应用/合并。 希望这可以帮助 ：） --- nuts_bolts.c.orig 2012-10-06 00:09:59.100195145 +0100
+++ nuts_bolts.c 2012-10-06 00:16:31.430258230 +0100
@@ -2,11 +2,11 @@
nuts_bolts.c - Shared functions
Part of Grbl
Copyright (c) 2009-2011 Simen Svale Skogsrud
Copyright (c) 2011-2012 Sungeun K. Jeon
-
+
Grbl is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
@@ -22,18 +22,35 @@
#include "nuts_bolts.h"
#include <stdint.h>
#include <stdlib.h>
#include <util/delay.h>
-int read_double(char *line, uint8_t *char_counter, double *double_ptr)
+int read_double(char *line, uint8_t *char_counter, double *double_ptr)
{
char *start = line + *char_counter;
char *end;
-
+ char saveChar = '\0';
+ uint8_t saveIndex = *char_counter;
+
+ if(line[saveIndex] == '+' || line[saveIndex] == '-') {
+ saveIndex++; // Skip over sign, if present
+ }
+ while (line[saveIndex] &&
+ ((line[saveIndex] >= '0' && line[saveIndex] <= '9') || line[saveIndex] == '.')) {
+ saveIndex++; // Find the end of the number
+ }
+ if(line[saveIndex]) { // Otherwise it's \0 anyway, no need to fixup
+ saveChar = line[saveIndex];
+ line[saveIndex] = '\0';
+ }
+ // strtod() will now see only the number and nothing beyond it
*double_ptr = strtod(start, &end);
- if(end == start) {
- return(false);
+ if(saveChar) {
+ line[saveIndex] = saveChar; // Undo the fix, if needed
+ }
+ if(end == start) {
+ return(false);
};
*char_counter = end - line;
return(true);
}
|
.jpg "nuts_bolts.c 中的 strtod() 可能会读取比您预期更多的行 #122"){kind=avatar}
|
唔。我能够测试并验证“E”字符是否以科学计数法正确解析，但不是您提供的“0X”十六进制示例。它正确地分隔了“Y”和“X”这两个词。不知道为什么这是不同的。我使用与 Arduino IDE v1.0 一起打包的 avr-gcc。我想知道这是否与它有关。 就科学记数法而言，我在我们使用的 NIST 标准中没有看到任何参考资料明确指出不能使用科学记数法，也没有将“E”字符保留为 g 代码字。我知道 g 代码在制造商和标准之间非常分散，许多词之间可能会有很大差异。你能提供这方面的参考吗？ |
|
我搜索了 NIST g 代码标准，其中有一节讨论什么是“数字”。它描述了一个仅包含“0-9”字符和可选的 +、- 和 的值。人物。所以看起来’E’已经出来了。 但是，我认为 protocol.c 中的 protocol_process() 是主动搜索此字符的更好位置，因为它已经在解析来自串行流的每个传入字符，并且可以向用户报告无效数字。 至于 ‘0X’ 十六进制的东西，我们需要找出为什么你会看到这个问题，而不是我在标准 grbl 版本上。 |
|
关于 protocol_process() 评论，我认为 E 字不应该从流中完全剥离，而是防止干扰 strtod() 的解析语义。我发送的 diff 只是其中一种方法，我相信还有很多方法可供选择 关于 实际例子：
|
.jpg "nuts_bolts.c 中的 strtod() 可能会读取比您预期更多的行 #122"){kind=avatar}
|
我看到了 0x 移植到 ARM 的问题（issue#94），我的快速修复是检查 |
|
案例和要点，Radu。我一直在思考如何优雅地解决这个问题。那么，在没有 base16 和指数解析的情况下编写我们自己的简化 strtod() 函数会有什么问题吗？代码看起来非常直接和简短，我们可以将它安装到 nuts_bolts.c 中。这似乎直接解决了这个问题，而不是建立一个检查系统。如果我理解正确，这甚至可以节省一些字节。 |
|
是的，编写自定义 strtod() 可能是最好的方法，因为所需的功能比原始功能少——因此代码大小的减少是可以预料的。 |
.png "nuts_bolts.c 中的 strtod() 可能会读取比您预期更多的行 #122"){kind=avatar}
|
还应注意，reprap Gcode 使用“E”来设置挤出机电机的速度。 |
strtod() 会将“E”解析为科学计数法，但“E”是 G-Code 中的一个词（而 G-Code 根本不使用科学计数法）。
strtod() 会将“0X”解析为 base-16 数字，这可能会给零件和工具带来灾难（想想 G01 Y0 X12：G 将解析为“1”，Y 将解析为 0x12 = 18 而不是 0）。
今晚我会为我的叉子想出一个修复程序，因为你的叉子也使用 strtod() ，所以打开它作为提醒。如果我的修复对你来说不错，请随意挑选它。