Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use ast.literal_eval instead of eval #73

Merged
merged 3 commits into from
Mar 21, 2018
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/genmsg/msg_loader.py
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,7 @@
possible layouts.
"""

import ast
import os
import sys

Expand Down Expand Up @@ -181,8 +182,7 @@ def convert_constant_value(field_type, val):
raise InvalidMsgSpec("cannot coerce [%s] to %s (out of bounds)"%(val, field_type))
return val
elif field_type == 'bool':
# TODO: need to nail down constant spec for bool
return True if eval(val) else False
return ast.literal_eval(val)
Copy link
Member

Choose a reason for hiding this comment

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

TL;DR I think that the logic for ensuring the return of a boolean should be kept here to preserve backward compatibility, aka return True if ast.literal_eval(val) else False.

Details: The new logic will make this function return numbers (integers or float) instead of python bool in the case where users provide numbers as a default.
For example the following msg file:

bool FOO=42
bool BAR=0
bool BLA=42.42
bool BLABLA=-42.42

currently results in (generated python message):

FOO = True
BAR = False
BLA = True
BLABLA = True

but with this PR will result in :

FOO = 42
BAR = 0
BLA = 42.42
BLABLA = -42.42

raise InvalidMsgSpec("invalid constant type: [%s]"%field_type)

def _load_constant_line(orig_line):
Expand Down